Is it recommended to use zsh instead of bash scripts?

Question

Can I assume that enough people have zsh installed to run scripts with a

#!/usr/bin/env zsh

as shebang?

Or will this make my scripts un-runnable on too many systems?

Clarification: I’m interested in programs/scripts an end user might want to run (like on Ubuntu, Debian, SUSE, Arch &c.)

Answer 1

For portability, no. While zsh can be compiled on any Unix or Unix-like and even Windows at least via Cygwin, and is packaged for most Open Source Unix-likes and several commercial ones, it is generally not included in the default install.

bash on the other end is installed on GNU systems (as bash is the shell of the GNU project) like the great majority of non-embedded Linux based systems and sometimes on non-GNU systems like Apple OS/X. In the commercial Unix side, the Korn shell (the AT&T variant, though more the ksh88 one) is the norm and both bash and zsh are in optional packages. On the BSDs, the preferred interactive shell is often tcsh while sh is based on either the Almquist shell or pdksh and bash or zsh need to be installed as optional packages as well.

zsh is installed by default on Apple OS/X. It even used to be the /bin/sh there. It can be found by default in a few Linux distributions like SysRescCD, Grml, Gobolinux and probably others, but I don't think any of the major ones.

Like for bash, there's the question of the installed version and as a consequence the features available. For instance, it's not uncommon to find systems with bash3 or zsh3. Also, there's no guarantee that the script that you write now for zsh5 will work with zsh6 though like for bash they do try to maintain backward compatibility.

For scripts, my view is: use the POSIX shell syntax as all Unices have at least one shell called sh (not necessarily in /bin) that is able to interpret that syntax. Then you don't have to worry so much about portability. And if that syntax is not enough for your need, then probably you need more than a shell.

Then, your options are:

• Perl which is ubiquitous (though again you may have to limit yourself to the feature set of old versions, and can't make assumptions on the Perl modules installed by default)
• Specify the interpreter and its version (python 2.6 or above, zsh 4 or above, bash 4.2 or above...), as a dependency for your script, either by building a package for every targeted system which specifies the dependency or by stipulating it in a README file shipped alongside your script or embedded as comments at the top of your script, or by adding a few lines in Bourne syntax at the beginning of your script that checks for the availability of the requested interpreter and bails out with an explicit error when it's not, like this script needs zsh 4.0 or above.
• Ship the interpreter alongside your script (beware of licensing implications) which means you also need one package for every targeted OS. Some interpreters make it easier by providing a way to pack the script and its interpreter in a single executable.
• Write it in a compiled language. Again, one package per targeted system.

Answer 2

No, you cannot. What is guaranteed available is /bin/sh, essentially the original Bourne shell. Almost all (note the "almost"!) Linux installations will have bash, but on *BSD systems it is rare (the BSD persuation has severe misgivings about GPL code, like bash). I don't know what the standard shell is on Mac, but again, there are misgivings about GPL. Same for Solaris.

zsh is a niche shell, it isn't in the default install of Fedora (and I don't believe it is default for any major distributon).

Answer 3

I think it really depends on what zsh extra features you're using and where. If you're planning to distribute your script across the different users and systems I would suggest to use bash or even sh.

The same time if your script designed to be executed across your organization and you have convention to have zsh on your machines (for instance the same basic AMI) and your task have clear benefits from extensions like advanced file selectors or other stuff from http://www.rayninfo.co.uk/tips/zshtips.html I would say go ahead!

Answer 4

As stated, bash is commonly available in the default installation for many distros. Your script will not reach the greatest user base by relying on zsh.

An important question to answer before designing your script is "Why does it matter which shell a script is executed in?"

Different shells use different syntax or offer additional shell functions that may not be supported by other shells. To write a script for the "general linux end user world," determine whether your script uses any syntax or shell functions that rely on a particular shell environment.

For example, bash shell supports certain expansions that are not supported by dash, Bourne shell, or whatever /bin/sh points to on the user's system.

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Try executing echo {1..10} with /bin/sh compared to /bin/bash and you'll get very different output.

The same goes for zsh which, while supporting most bash syntax, offers additional expansion and syntax that is not supported by the bash shell. See this tables comparing shells for specific examples.

You could broaden your potential user base beyond bashby adhering to scripts that work when called with #!/bin/sh -u. However, this gives rise to another important question to ask: "What is being sacrificed in exchange for greater portability?"

Determine whether differences relating to security concerns, functionality, efficiency, or anything else you feel is a priority for your script would be worth the sacrifice. You may not want wide spread use of a script with a known security vulnerability just because it works in more environments.

So many scripts are written for bash that support for these scripts is used as a criteria when comparing command shells. Many more people will be able to run your script than if it relies on zsh or any other syntax exclusive to a shell environment.

Also, keep in mind that you don't ultimately have control over how the user executes the script (also useful for debugging scripts in different shells):

Remember that if you use a shell to read a shell script (“sh scriptname”), instead of executing it directly (“./scriptname”), the shell will treat all the comments at the start of the shell script as comments. In particular, the comment that specifies the interpreter to use when executing the script (“#!/bin/sh -u”) will be ignored, as will all of the options listed beside that interpreter.

So, the best you can do about this is make your scripts portable, so long as there is there is no great sacrifice to how it functions.

You might also see Bash coding conventions - Stack Overflow.

Answer 5

The only thing you can almost guarantee is that there is a /bin/sh. That might be an actually static linked shell, or it can be a link to another shell. That other shell usually detects that it is called as sh and will run in compatibility mode.

Notice the almost in the first sentence.

Every unix like system I ever worked on had it. Many of them also had bash installed (but not all of them. E.g. bash it is not installed by default on some BSD's. Some Linux distribution ship with DASH, the Debian Almquist shell instead.

What you can guarantee are your installation instructions. You can add a line to the README file stating that is needs zsh. If you build a package then you can mark zsh as a dependence. You can check for it with the autoconf/automake tools. You can check if zsh is found with in installation script (start with /bin/sh and try to locate zsh, if found continue. If not display an error. e.g. "Warning: ZSH is not installed. Please read the installation instruction file!".)

I am sure I forgot a few more options. But the key points are:

• You can guarantee nothing until you checked for it.
• You are almost guaranteed that /bin/sh is present, and that you can do some checking with that.