It seems like most of the features listed as better than bash are either a) covered by bash 4.0, b) bad ideas (shared history among sessions), or c) only controversially better (searching around, people seem to argue back/forth about which programmable completion implementation is faster/better).

1) it's a drop in replacement for bash. All those scripts you have around have #!/bin/bash at the top, they will still work exactly as they always have.

2) You can selectively go back through your command history. You can arrow-up to go to previous commands just like in bash. But if you start a command (say, ssh) and then arrow-up you will then be cycling back through the last ways you entered that command. Super convenient.

Like Ctrl+R?

Or, if you'd like to do this in Bash, and any program that uses readline: In ~/.inputrc

    # Bind the up arrow to history search, instead of history step
    "\e[A": history-search-backward
    # And the reverse (down)
    "\e[B": history-search-forward

    git clone
    git rebase master
    git log

    git r<UP>

  bindkey "^[[A" history-beginning-search-backward

If you don't want to use it, I don't see how that is any of my business. I was just trying to help out somebody who does, so there's hardly any reason to be an ass.

All I'm saying is that most people won't like something that offers no immediate major benefit and has annoying defaults that they have to find an obscure setting to fix. This is probably why so few use emacs, even though it is awesome :)

Of course, a script that has #!/bin/bash at the top will keep working regardless of which shell you execute it on anyway, even a shell with a completely different syntax such as tcsh, because that shebang line will tell the OS to always use bash to execute the script--no matter what shell you're using to invoke the script.

It's different when you source a script (usually done using the eponymous shell built-in) since then the shebang line will be treated as a comment and ignored, and all other lines in the script will be executed in the context of the current shell.

1. Learn bash better. Lots of low-hanging fruit there to increase your productivity with minimal effort.

2. Learn how to customize your environment in bash. Know what every line in your dotfiles does. Add to your dotfiles gradually as you learn.

3. If you learn about some cool features in zsh, see if bash has the feature already. If it doesn't, see if you can mimic it easily with your own functions or scripts.

4. If you still want more features, make the switch to zsh and repeat steps 1 and 2 with zsh.

I think the worst is when people see a novel trick and switch to zsh and slam in oh-my-zsh* without knowing any shell basics. Now you have another shell and a big pile of code and you don't understand any of it. This usually won't cause problems, but you almost certainly won't be getting the most out of your shell. You'd be better off in most cases just digging into bash a little deeper.

I use zsh now, but I only switched after learning what bash could do and what its limitations are. I'll reevaluate zsh vs. bash 4.0 at some point, but for now I see zsh installed by default more often than bash 4.0 and it seems to me that most users interested in the best interactive shell experience are still on zsh and I like to learn from them.

* - I think oh-my-zsh is a great project - I'm not knocking it. I've borrowed lots of great stuff from it. But I think you should understand every line of code you are dumping into your environment, whether you are using oh-my-zsh or not.

While a senior in high school (~15 years ago), I was also enrolled at the local university and taking a few 1000- and 2000-level Math and CS courses. About halfway into the spring semester, my account on the CS department's crusty old Sun box was locked, and my CS professor that semester told me to report to the system administrator's office after class.

When I arrived at the system administrator's office, the department's system administrator and the department head were waiting for me. The sysadmin immediately (and angrily) said that if this were anywhere but a university, he'd see that I was thrown in jail. When I asked what he was talking about, he turned to his computer, banged on the keyboard for a bit, and turned the massive CRT so I could read it.

On his screen was an e-mail I had sent him the semester before asking that he change my shell from /bin/csh to /usr/local/bin/zsh. (Solaris of that vintage didn't have chsh, so I couldn't do it myself.)

The sysadmin was absolutely convinced that zsh gave me "elevated system privileges", even though he was the one that changed my passwd entry and presumably was the one who compiled and installed zsh in the first place.

When I argued that /usr/local/bin/zsh didn't have the suid or sgid bits and therefore gave me no more access to the system than any other shell, the department head scolded me for arguing with the (experienced, wise) sysadmin.

The sysadmin changed my shell back to csh, and the department head made me sign a document stating that I wouldn't change my shell back to zsh or try to "further gain administrative access" to the system.

On the drive home, I idly wondered whether going to (a different!) college full-time in the fall was really such a hot idea...

You should have never signed that. Even if you struck the word "further", it'd probably be seen as an admission of guilt in court.

The little itch that drove me crazy was command-line editing: in bash (and all readline apps) when I have

   command long/path/to/some/file

I tried various hacks to make zsh do the same, then gave up.

    bindkey '^[^?' backward-kill-word 

Edit: I know I can customize the word style using $WORDCHARS, or 'autoload select-word-style'; my problem is that I'm used to having the capability to use two different word styles at once.

I'm looking through the command list in zshzle(1), and I'm a bit confused about the differences between backward-delete-word and backward-kill-word. Some short experiments I did failed to notice any differences (foo/bar/baz M-x backward-delete-word deletes foo/bar/baz). There's also vi-backward-kill-word which deletes 'baz', then '/', then 'bar', then '/', then 'foo'. I want a key to delete 'baz', then 'bar/', then 'foo', and I've no idea how to get it...

The other alternative is to try:

    autoload -U select-word-type
    select-word-type bash

Internet Explorer is the default on Windows because Microsoft makes it, not because it's the best option for a default.

Bash is the default because it's the best shell to be used as a default. Nobody is twisting the arm of any distribution, but they set it as the default anyway. There's a reason for that.

How often is this decision re-evaluated?

...personally I just hit Ctrl+C again to reset my prompt.

Also, because it's GNU. Just as IE is the Microsoft browser, bash is the GNU shell, and most Linux distributions are built around GNU userland.

But that's just Linux. The BSDs don't see bash as the best default, where it tends to only be available as an optional package.

Bash has come a long way since then and it's just a "brew install bash" away. There's absolutely no good reason to stick with the version that ships with OSX for your personal shell.

I'm not sure which zsh OSX ships with, but it should be much more up to date since it uses a BSD-like license.

"Legally capable" is one thing, "completely out of any possible problems in the future" is another.

GPL3 is toxic.

1) Patents, i.e. you can't circumvent GPL3 by using GPL software as something you build your software on, but then don't share it because while source code may be available, you patent the code. It was possible with GPL2.

2) DMCA, i.e. you can't circumvent GPL3 with using DMCA which makes circumventing DRM illegal in US. It was possible with GPL2.

3) Tivoization, i.e. you can't circumvent GPL3 using digital encryption, when you release the source code, but not the necessary cryptographic keys.

In other ways, GPL3 is pretty much the same as GPL2. Using GPL3 bash would not make Apple release source code of Mac OS X any more than using GPL2 bash. The only reason not to use GPL3 (1) is when you don't want the three things I listed above taken from you. I would suggest that makes any company with "no GPL3" policy toxic, not GPL3.

Should you want to educate yourself, here's a link that explains it pretty well: http://www.linuxfordevices.com/files/misc/GPLv2_vs_GPLv3.pdf

(1): It's very different with AGPL

Power beyond need or capability is complexity (the bad kind).

Part of this is because I try to automate anything I do more than once or twice and I use a real language to do so. For anything non-trivial the differences between zsh and bash are an order of magnitude less significant than either compared with Python, Ruby, etc.

In brief, bash, like mysql (or Windows) is always there. Most people know how to use bash and wouldn't notice any difference by switching (except for a possible unnecessary learning curve).

Lets turn it around. Assuming (and a big assumption) that zsh is more powerful, why does this matter to someone who probably spends most of their time at a terminal thinking and puts anything half way repetitive into a script? Its like telling a carpenter than a brand X chisel is more powerful than a brand Y chisel.

Show me how a skilled zsh user is 'more powerful' than a skilled bash user at anything that matters. Perhap some people spend too much time typing and not enough time thinking.