Better for what?

What are your criteria?

Personally I suggest bash because it’s the default on Linux and MacOS X systems and readily available on all other forms of Unix and under MS Windows through Cygwin and is the default for the Microsoft™ Windows Services for Linux” (Ubuntu bash support layer/subsystem).

Basically it’s the path of least resistance if you’re going to operate many different systems across many years … and frequently will be accessing freshly re-imaged systems or fresh launched instances with minimal deviations from the OS base (as is common for scaled web/app server farms). It’s close enough to Korn shell that few people will find the corner cases where they differ in semantics. (Most users won’t notice the difference between more minimal Bourne shell clones such as ash and dash and the features that bash adds, much less be able to distinguish between the differences between ksh and bash.

zsh is probably the most powerful and customizable. It’s best suited for someone who’s truly passionate about using and customizing their shell. The downside of using it … with all its enhancements and customizations … is that the user is likely to find it frustrating to back down to using some other shell when debugging issues on systems where zsh has not (yet) been installed — which is something that the ops/sysadmins folks in modern environments do fairly frequently. It’s also rather unhandy when working with or mentoring colleagues and trying to show them something at their shell prompt or sharing a GNU screen or tmux session with them.

The Korn shell, ksh, is a better shell for scripting than bash in a few minor details … but not enough to be worth having to fetch, install, and configure it everywhere.

ksh supported “associative arrays” (hash/dictionaries) for many years before bash added it. (It was only added to bash a few years ago, is still not included in the versions that ship with MacOS X by default, for example). So it’s usually best to simply not use associative arrays in your shell scripts. If you think you want its features then usually it’s best to switch to Python, Ruby, Perl, TCL/wish or any of a number of other general purpose scripting languages. There just isn’t that much to be gained by switching to a different shell (in terms of operational overhead) just for that one feature.

The same can be said of ksh Coprocesses.

The only other notable difference is one which must be explained. Consider the following shell command:

unset foo; echo bar | read foo; echo "$foo" 

This is perfectly valid in any Bourne compatible shell. But it will behave differently under various shells. It will either emit the string “bar” (and a new line) or it will emit just the blank line.

bash will do the latter, while ksh and zsh will perform in the former manner. The “foo” shell variable will be set in the current shell. In my opinion that’s the preferred semantics.

But this is a corner case. So far as I know it’s not covered by the Posix specifications for the Unix shell; so the fact that the behavior is implementation dependent is not a bug. This is merely something that an expert in the shell must be aware of and either test for or work around.

The reason for this behavior is that the “pipe” operator in the shell is an inter-process communication mechanism. The shell must create a subshell, that is a subprocess running its own copy of the parent process’ memory. However, any given implementation can parse the command and run either the part before (to the left of) the pipe symbol in the subshell (as done by ksh and zsh) or after (to the right of) the pipe (as done by bash, very old versions of ksh (prior to 1983 release?) and the older Bourne shell and most of its clones such as ash and dash.

One work around is to use command grouping to ensure that all of the commands after the pipe are “in scope” with the read built-in like so:

unset foo; echo bar | { read foo; echo "$foo"; } 

(Incidentally, this example exposes a subtle bug which existed in bash prior to 1.4 and which was fixed thereafter; the parser used to treat {} characters and tokens very much like the () (parentheses). So it used to tolerate leaving out that semicolon after my echo “$foo” — which was, technically, a deviation from the spec. The problem is that millions of people were using bash and writing scripts based on the assumption that they didn’t need to terminate their command before a closing brace — with a semicolon or a newline. So some of these old shell scripts are still exhibiting this bug well over a decade later and there are only a handful of people who know the shell well enough to spot and fix it).

As for interactive use, bash is clearly superior to ksh but probably not quite on par with zsh for anyone who would commit to learning and using deeply tricky enhancements and customizations.

bash supports programmable [Tab] completion and the GNU readline libraries for extremely flexible control over keybindings, command line editing and access to one’s command history. ksh has the relatively limited fc command (which bash also supports) for your “fix command” — that is to select items from your history, pull them up in your preferred text editor, and automatically execute the contents of that edited temporary file on exit.

But bash supports that and its own emacs or vi history access and editing, and the old csh ! (bang) operators as well.

bash support vi editing mode (set -o vi) which was, if I recall correctly, the default in ksh 93. But bash defaults to the emacs mode (set -o emacs). Additionally, of course, one can also use the bash bind command to re-bind any keys to any of a large number of editing and history manipulation functions, or into macros expanding into any text you might want to put on a command line.

Additionally bash has many “magic” environment variables which can do things that are almost unimaginably subtle and intricate. For example, you can set the PROMPT_COMMAND variable to execute a custom hook every time bash is about to present its prompt. So you could have that check for some magic .dot_file and re-customize your running shell based on what directory your in, or reset your prompt string and terminal screen colors based on the time of day, or query some website and automatically execute some command based on … just about anything.

(I’ve used that hook to automatically activate Python virtual environments by simply changing to their working directory for example).

When you consider tcsh (or its ancestor, csh) then you’re in a bit of a niche. It’s common to see csh scripts in the field of EDA (electronic design automation). But that’s an accident of history and most of the people working in that field don’t use tcsh for their interactive use.

The fish shell is also a niche. I’ve never used it enough to form an opinion on it, and it’s certainly colorful enough. But I think it’s going to have a very tough row to hoe before it cultivates a truly widespread following. Unless Apple™ starts shipping it as the default shell for their Mac™ systems it’s probably doomed to remain in its niche for the foreseeable future.

So I hope I’ve made the point. There really isn’t much point to asking “what’s the best …” (of pretty much any thing where there are reasonable alternatives).

In the case of Unix command shells the differences among the Bourne compatible shells are so minor that only experts can tell them apart, and those have trade-offs and eventually boil down to rather subjective preferences. I have colleagues who are passionate for their zsh settings and others who just down care. I’m somewhere in between having adapted myself to the most readily available choice.