Find me a real world case where switching from bash to zsh was a bad idea.
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.
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-backwardIf 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.
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