The UP ARROW works with any reasonable shell
With ZSH you can also have completion with TAB and RIGHT ARROW keys [with plugins I have enabled].
Uhm, I don't think so. Bash, by itself, is just a pretty good POSIX/bourne-based shell with lots of nice features. Still fewer than zsh (and also less liberally licensed if that's important for your scenario), but anyways, it's a pretty good shell.
I'm not comfortable with any C shell, and I don't intend to ever change that. It has a tradition on BSD, sure, but that doesn't mean I have to like it
. Thankfully, there's a POSIX shell in base and for everything else, you can install whatever you like from ports In the past I used CSH/TCSH/SH for root and then switched to ZSH (by typing zsh on the root prompt) to switch to usable shell.
if [[ ! -o interactive ]] ; then return; fi
setopt notify cdablevars autolist autocd recexact \
longlistjobs histignorespace histignoredups histfindnodups \
pushdsilent ignoreeof mailwarning
if [[ $UID = 0 ]]; then alias sw=suspend; else alias sw=%su; fi
PS1="%* %m:%5. %h%(#.#.:) "Regarding this ... zsh explicitly doesn't guarantee POSIX compliance (which is just a wise thing to do, the more extensions/features you provide, the more likely it is to accidentally violate some POSIX behavior). Still it offers lots of zshoptions(1), and emulation modes setting many of them ... and the emulation mode for sh/ksh is probably close enough to POSIX sh.
Explain what you mean by fast and slow. I don't see how a shell can be at all performance-relevant on a modern system.
That is some stable and well tested config there
Yes, you're quite right, that was very careless phrasing on my part. The associated "Linuxisms" do not in fact have anything to do inherently with the shell itself (which I do like a lot and feel very comfortable using!), but with scripts that assume the availability of bash extensions, rely on bash-specific syntax, or use the shebang
#!/bin/bash (instead of, say, the more portable #!/usr/bin/env bash). Not the end of the world, but not always great for portability, either.
#!/bin/sh and then rely on subtle things that happen to work in bash's "sh emulation" but aren't guaranteed by POSIX at all 
-- that's somewhat less common nowadays as many Linux distributions install some more minimalistic shell as /bin/sh, but in a "vanilla" GNU userland, /bin/sh will be provided by bash.#!/usr/bin/env bash will work in most systems as long as bash is available in PATH, even that isn't fully portable. In fact, no hardcoded shebang is ever fully portable, because POSIX won't guarantee the absolute path to any of its utilities, including the POSIX shell itself. This means if you want to distribute a POSIX shell script in a fully portable way, you have to include some "installer" that finds the POSIX shell and substitutes the shebang on installation... the recommended way to do so is to walk the path returned by getconf PATH looking for a binary named sh.Annoyingly zsh has a dependency on perl (on FreeBSD).
It fulfills this specification:
Sure. But it can be pretty hard to offer extensions without breaking some aspect of the POSIX specs. Many capable shells have different modes (including one POSIX-compliant one, or, like zsh, an sh/ksh emulation that's specifically NOT guaranteed to be compliant, but, err, somewhat likely ....)
If you keep all your scripts to yourself and you have zsh on all the machines relevant for you, that's great and nothing wrong about that. But it's completely irrelevant in the context of portability. Any portable shell script should strictly adhere to POSIX.
