This list is great (and old), but what I would really like is a more concise list of stuff zsh can do that bash can't, and that has been vetted by people who know bash well. (like one thing that comes to mind is recursive globbing with two astersisks, but to be honest I have no clue if maybe bash can do that too by now).
The reason why I want such a list is I usually point people to zsh-lovers list who ask me why I use zsh, but something more to the point would be great, and probably more convincing.
The parent was wrong, and bash can't do the thing he MEANT. The above aren't globs, they just generates strings. None of those files need to exist. In zsh you can use
<7-10>.txt
to match 7.txt, 8.txt, 9.txt and 10.txt. Zero-padding is loose. 07.txt and 08.txt match also, for instance. The bash {..} syntax just doesn't handle this variable 0-padding case, which is extremely common when looking at a directory full of photos, for instance.
This[1] talk is kind of old, and I'm sure bash now has some of the features only zsh had at the time, but it should give you a feel for how zsh differs from and improves on bash.
Another thing I suggest doing is joining #zsh on freenode, and asking your questions there.
Yet another thing you could do is skim through the zsh user's guide[2], which is also kind of old, but is pretty comprehensive (for the time), and will give you more of a feel for what zsh can do. zsh's man pages are also very comprehensive (and huge), and might be worth a peek.
Also it is worth nothing that Bash does get updates and newer versions get some features that zsh has. So if it made sense to switch in the past perhaps it no longer does. 'etc.
Sometimes I wish there wasn't so much duplication of effort in this world..
On Ubuntu at least, when you install virtualenvwrapper from apt, it drops the file you need to source into the bash completion directory[1], presumably so that it will be automatically loaded when bash launches. As a zsh user, this annoys the hell out of me. If they dropped it in $PATH, then you could just do:
source virtualenvwrapper
and be done with it. I guess that's a (small) hit against zsh though. :P
I created some screenshots [1] showing some things, menu based tab completion, global aliases, included vcs prompt support for git, svn, hg, bzr, cvs etc.
There are plenty more features like for example hashed directories, e.g. shortcuts to a directory:
The project is quite old already and could need some love. If someone wants to contribute, it's available on GitHub: https://github.com/grml/zsh-lovers
A more recent project similar to zsh-lovers is http://grml.org/zsh-pony/ - this are the notes from a talk I gave at DebConf 2011 and also covers some nice features of Zsh. Should be easier to go through that than through zsh-lovers if you're interested in an introduction of nifty features.
I guess the reason why no up2date list of "what Zsh can do but Bash can't" exists is that most people who explore Zsh never really look back to Bash once they went the Zsh route. Bash v4 got some features from Zsh but there are so many small things that Zsh still provides that once you get used to them you never want to go back. :)
Same, i'm rather new to using zsh but it would help greatly if there was a comparative list between bash and zsh defining the differences. It was suggested to me by a couple of friends but at this stage, i'm not clear on why I would benefit from using zsh over bash.
I don't know if bash has this, but some commands have tab-completion on the arguments, with a listing for multiple hits:
$ tar --c<tab>
--check-device -- check device numbers when creating incremental
--check-links -- print a message if not all links are dumped
--checkpoint -- display progress messages every NUMBERth record
--checkpoint-action -- execute ACTION on each checkpoint
--compare -- find differences between archive and file system
--compress -- filter the archive through compress
--concatenate --catenate -- append tar files to an archive
--confirmation -- ask for confirmation for every action
--create -- create a new archive
sudo aptitude install bash-completion #or apt-get install...
#Then in your .bashrc do something like:
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc).
if [ -f /etc/bash_completion ]
then
. /etc/bash_completion
fi
The latter (or equivalent) is already in /etc/skel/.bashrc on Debian at least (provided by the bash package), so users created with eg. adduser already have this in their .bashrc. IIRC it may be commented out in Debian stable - I currently run testing, and /etc/skel/.bashrc there contains:
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
Install the bash-completion package. [1]
You'll then find a directory /etc/bash_completion.d/ which has all of the commands the package knows about. The number of commands can be extended.
There's just a lot of nifty little features. Two of the most important for me have been shared history between my 20+ terminal sessions, and properly handling wrapping of the command prompt. I am sure bash can wrap properly, but I couldn't figure out why it wasn't and zsh never gave me that problem!
I've been using zsh as my primary shell for roughly 5 years. I made an earnest effort in the beginning to read the 400+ page User Guide[1]. Though I learned a lot, it's simply to much information to retain-- especially the things you don't exactly use often. For me, "quick reference" materials like this list have become essential. I've resigned to remembering only the important stuff that I need daily, and for the other things (say, how to write your own completion file for a command that takes a bunch of different types of parameters) I simply remember where I can look it up (the links section of zsh-lovers is probably the most useful simply for this reason). And when I can't do that, #zsh on freenode has been a genuinely helpful community.
The reason why I want such a list is I usually point people to zsh-lovers list who ask me why I use zsh, but something more to the point would be great, and probably more convincing.