WTF?<p>I wrote this slide deck. It was a presentation I made for a monthly "tech lunch" my team has.<p>I made it after a couple of weeks of messing with zsh. It was for an audience of 4 other people who knew less about zsh than me. I can't believe someone posted it to HN!<p>That explains the "this slide deck is getting traffic" email I got from Slideshare this morning.
That's actually the first time I've seen a decent set of reasons why zsh is worth using. Well done.<p>Almost every other "Switch from bash to zsh, it has this awesome killer feature" article I've seen has raved about a feature that's available in Bash & has been for years.<p>I'm starting at a new job in a month or so, I shall try & use it as an opportunity to switch to zsh since I won't have any can't-live-without bash shortcuts in place at that point.<p>(Last time I tried switch to zsh, it took OMZ to get it useable, but it also made it too slow to live with. Hopefully starting with a clean slate will do the trick)
While zsh may be more 'useful', I find it a bit too smart. Many of the features are very interactive, and introduce a non-determinism that messes up my ability to fix errors. An example is command correction. I (usually) know when a command is wrong, and go to fix it without thinking. Being asked if you really meant some other command interferes with this, and while seemingly helpful, makes you wonder if a shell should really be doing that.<p>The directory listing shares the same problem. Once you have a list, it's just as easy to type the path then it's to cycle through the list (not that zsh stops this), it's just another interactive feature.<p>Then there is path-completion, which removes the / on the end of tab-completed paths. Since rsync treats a directory with / different to that without one, this feature annoys me to no end when using zsh.<p>I understand that all these are options, and could easily be configured. I just wonder how other people feel about them. Does anyone actively use these features? Do you find they can occasionally get in the way?
I like process substitution feature in zsh. In bash you can write:<p>vimdiff <(ls /bin) <(ls /usr/bin) [ It is an example. In real world, I use this feature for comparing outputs of one version of program with another one ]<p>And this will create two pipes, where output of each ls will go. Unfortunately, vimdiff sometimes needs to do second pass on the files, so this command won't work properly when outputs are large.<p>But in zsh you can write<p>vimdiff =(ls /bin) =(ls /usr/bin)<p>and this will create temporary normal files, instead of just pipes, and vimdiff will work fine.
I think the zsh-vs-bash debate is centered on minimalist vs. full-featured. For instance, the git completion example is very ugly in zsh to me. I know what git commands do, and I'd much prefer for the completion to take 1-2 lines total than one line per possible command, as in the zsh example. The prompt examples are similar -- my PS1 is<p><pre><code> local green="$(tput setaf 2)"
local reset="$(tput sgr0)"
export PS1="\[$green\]>>\[$reset\] "
</code></pre>
And a multiline prompt, let alone one with right-justified elements, is pretty gruesome to me.<p>The first slides about availability on Macintoshes don't resonate, because I'm going to have MacPorts on any dev box and use that to install the latest. It's more likely I ssh to a server that has Bash 4 and no Zsh than anything else, so it also makes sense to know bash and have a good .bashrc ready to scp up there if I'm going to be doing a lot of work on the server.<p>zsh spellcheck is very annoying, thankfully it can be disabled. This is my preferred spellcheck solution ;^) <a href="https://github.com/mtoyoda/sl" rel="nofollow">https://github.com/mtoyoda/sl</a><p>All that being said, zsh is a really cool piece of software. It's one of those things I've always wanted to really stretch to its limits, but I've never been able to hang with it for more than a few months, which I doubt is enough time to really become accustomed to the workflows zsh allows (like the /u/b/... expansion example in the slides).
The article with Knuth's program and Doug's reply is: <a href="http://dl.acm.org/citation.cfm?id=315654&CFID=329016541&CFTOKEN=58713819" rel="nofollow">http://dl.acm.org/citation.cfm?id=315654&CFID=329016541&...</a> (Don't have a non-paywall version.)<p>Regarding the claim about Knuth's program being long, it is worth considering that (1) his program was primarily a demonstration of literate programming style, which contains considerable embedded documentation (2) the program needed to build significant basic infrastructure to support itself, including IO, sorting, case equivalence (including a table with each upper-case and lower-case letter), etc.<p>Doug's criticism and comparison of Knuth's solution vs. his own is insightful worth reading.
One thing I don't see mentioned nearly enough is, if you're using extended globs, it's possible to tab-complete virtually all of it, which doubles as a handy reference.<p>For example:<p><pre><code> setopt extglob
cd *(<tab>
~~ massive spam of possible glob qualifiers ~~
</code></pre>
and it works for variable expansion modifiers as well:<p><pre><code> print ${(<tab>
~~ completion candidates for parameter flags ~~
print ${<tab>
~~ complete any currently set variable in the current env~~
</code></pre>
Another thing I like is the array types for things like $PATH that are historically colon-separated, typically
lower-case versions of the var name for the interesting 'magic' ones.<p><pre><code> vared path
</code></pre>
vs<p><pre><code> vared PATH
</code></pre>
to see the difference.<p><pre><code> print -l $path # much easier to read</code></pre>
I see your zsh and I raise you fish: <a href="http://ridiculousfish.com/shell/" rel="nofollow">http://ridiculousfish.com/shell/</a><p>Try it. It's better.
I use bash as my everyday shell since 1996. I keep on reading the "how great zsh is" articles. And I always try zsh. But after a few minutes/hours, I go back to bash. It's really hard to change.
Path replacement is also possible in bash, as in:<p><pre><code> cd site1 site2
</code></pre>
if you just add this line to your ~/.bashrc:<p><pre><code> function cd() { if [ $# -eq 2 ]; then builtin cd ${PWD/$1/$2}; else builtin cd $1; fi }</code></pre>
I find the way ZSH does completions for git kind of frustrating. It's a bit overzealous and so when you try to complete a remote branch lie:<p>"git co br<tab>"<p>It finishes with:<p>"git co origin/branch"<p>Whereas what I want is:<p>"git co branch"<p>because I have git set up to automatically create a local branch and set it up to push to the remote when I do that. Just a small annoyance. Overall I find ZSH has cool features that don't actually work that well, or at least they don't do all that much for me. Spell checking, for example, is rarely that useful since it tends to show up for commands that work fine. It really needs an option to say "never correct this" but it doesn't.<p>That said I still use it, don't see any reason not too. I mean, Powerline for ZSH looks gooood. Just not sure it's <i>that</i> much better than other shells.
Only through zsh did I find out about tab auto-complete.<p>When I used bash, whenever I needed to uncompress a tarball I downloaded, I would type in the full, ~50 character filename. Only through zsh did I find out about tab autocomplete, and when I had to use bash on a friend's Mac, to my surprise, autocomplete worked.<p>I still use zsh, though.
I love using zsh (in combination with oh-my-zsh) on OSX but the only thing I've noticed after using it a year is that it's becoming very very slow. As in, it usually takes me 5-10 seconds to login to a new session (locally) and be able to see the prompt and type something.<p>Tab auto completion takes a second or two (even for files).<p>Combined with the git plugin I have enabled (which does "git status" on every prompt in a git folder) it's almost unbearable to work with.<p>I've looked into it a couple of times, there are some people with the same issues on oh-my-zsh's github, but I could never really solve it.<p>Would any pro zsh user know what my issue could be? I'm seriously considering going back to bash, I use it at work and it reminds me how fast the terminal can be.
After using zsh for a while I moved back to bash. The main reason is that I want to learn bash well, because I might be writing shell scripts in the future and I don't want to use zsh specific features in my scripts so I don't want to get used to them.
The killer feature to me is scp completion, e.g.<p><pre><code> scp someuser@someserver:<tab>
</code></pre>
… will ssh into the server, fetch the file list and offer it for completion locally (granted you have set up public key authentication)
I've been using zsh for a while now, mostly without using any special feature that isn't available (maybe with some tweaks) in bash.
The additional value for me is that I get all of this out of the box, or with not much effort. That's to oh-my-zsh I've got a nice looking theme (agnoster). Thanks to "zsh-syntax-highlighting" I get syntax highlighting, thanks to "history-substring-search" i got a nice way to search in my command history. All of those just took less than one minute to set up on my machine.<p>Luckily enough, I don't have to work over servers which may or may not have zsh, so i don't need to worry about that. Whenever I have to use a PC with bash (or any other *sh), I can easily get the same result, with a slightly-worse user experience.<p>Also, as a nice tip, zsh will complete "kill" and "killall". So that I don't have to fire up htop every time I want to kill a process.
Path expansion, can easily be fixed with something like this
in bash:
CDPATH=".:..:~:~/Desktop:~/Documents:~/Documents/Prj:~/bin:/usr/local:/usr/local/share:/opt/local"<p><pre><code> for realm in ~/Library/Caches/temporaryitems ~/* ~/Desktop/* ~/Documents/* ~/Documents/Prj/* ~/Library/* ~/Library/Scripts/* ~/Library/
do
for folder in $realm
do
if [ -d ${folder} ]
then
* CDPATH="$CDPATH":"$folder"
fi
done
done</code></pre>
As for completions of git and such, that relies totally upon where you got your completion from.
There gotta be better arguments than this, and I am really sure there is.<p>I am on Mac OsX, and I downloaded and installed bash 4.2, and I have never experienced any problems with that.
My favorite feature that wasn't mentioned is completions for `kill`. For example, in bash I would have to `ps -ef | grep command_I_ran` then `kill -9 process_id_of_command_I_ran`. Bonus points if you can do that in one command! In zsh, you only need to do `kill -9 partial_command_i_ran[tab]` and it will complete it for you. Also, !$[tab] and the like. Also, you can set the theme to random to get a surprise every new window.
The only thing that is keeping me from 100% zsh is that zsh is not everywhere and bash is. When you switch companies, sometimes admins/IT are not flexible in allowing zsh to be installed on build/vnc servers. Can anyone share some tips on how to manage dotfiles for zsh with backwards compatible bash so that you can truely have a portable config?
Normally, these slideshares are difficult to follow since the subtleties of an actual presentation are missing. This is not the case here: kudos to the author. After reading the comments that I can transfer over all my .bash_* information, I will be doing so.
My personal favorite zsh specific feature is the REPORTTIME environment variable. When set to a nonzero number it'll automatically print a summary after a long running command.<p>My own <a href="http://imgur.com/6LCS1cj" rel="nofollow">http://imgur.com/6LCS1cj</a>
I'm really glad I switched from bash to zsh a few years ago. zsh is, IMHO, a tiny bit better than bash in many areas. Because I use it all day every day, these little bits better add up to a lot of benefit.
I really enjoy the regex completion.<p>Example:
$ rm * .gch dir/* .gch<p><tab><p>$ rm file1.gch file2.gch file3.gch file4.gch dir/file5.gch<p>I really enjoy it when I'm removing something sensitive and just want to make sure.
I switched back from zsh <i>to</i> bash, and I miss it terribly. Problem is, I need to run both virtualenv and rbenv, and they're both designed for bash, and don't work properly with my zsh for some reason.