How zsh is more useful than bash | Hacker News Reader

How zsh is more useful than bash

slideshare.net

234 pointssiamore147 comments

WTF?

I wrote this slide deck. It was a presentation I made for a monthly "tech lunch" my team has.

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!

That explains the "this slide deck is getting traffic" email I got from Slideshare this morning.

I had just switched to zsh and found your deck when searching for something like "zsh features", I thought "hey this is great for starting out with zsh and maybe a good post for HN". Thank you for releasing it for everyone to see.

I'm glad that you and other people found some value in it. When I saw it here, I was worried the comments would tear it to shreds. :)

It was just a bit of a shock when I clicked the link. Since the link title was slightly different than what I named my slides, I just thought, "oh hey, another zsh comparison, let's see what this guy/gal said"...

Mostly, when submitting a post I refrain from changing the original title but I thought "How zsh is more useful than bash" would be better than the original. BTW I'd probably feel the same way too but the deck seems to be well received

I enjoyed the slides. Great job!

Many people like me are new to whole Unix system and need trainings like this. I did not even know that I can upgrade my bash via homebrew.

I don't dare to switch to zsh yet. I'm afraid if it messes up all my bash_profile, rvm stuff and Vim configs. I have a bad memory with fish_fish

zsh touches none of the above. You should be good!

Zsh won't mess with any of your configs. But even if it did, you'll probably never look back anyway once you make the switch. It does everything you're used to Bash doing, except more, and better.

Zsh was a drop in replacement for me. Worked perfectly with everything you just mentioned.

You wrote a powerpoint for a four-person lunch?

That's actually the first time I've seen a decent set of reasons why zsh is worth using. Well done.

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.

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.

(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)

You can easily drop your existing BASH aliases, etc, into .zshrc and not even notice that you've switched to zsh.

As for "Oh My Zsh," I've never seen any reason to use it, as zsh works fine without any add-ons.

  | As for "Oh My Zsh," I've never seen any reason
  | to use it, as zsh works fine without any add-ons.

I'll second this. I've never found a need to use "Oh My Zsh," and I've been using zsh for a few years.

> 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.

Yeah, I feel the same way. Most people seem to act like bash doesn't have tab completion or customizable prompts or something. This is actually the first time I've seen actual useful features of zsh that bash actually does not have (path expansion for instance). But I actually have my own little workaround scripts for those types of things that I'm used to so I don't feel a huge compelling reason to switch. The multiple shell history thing is a pretty good reason though. Maybe I'll switch eventually.

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.

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.

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.

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?

The command correction really bugs me in ZSH. 99% of the time it's wrong, and it doesn't learn even after the hundredth time of me telling it "no that's not what I meant, stick with the original". I keep thinking I should try writing a Bayesian filter for it or something, which would be a fun little project, but too low priority.

Also annoying when I start a command with sh, hit tab to command complete it with a .sh script in the current dir, and the command completion shows not just the .sh script but a bunch of shell commands as well. Pretty sure 'sh' should filter all those out and return only 'example.sh'. I don't recall this happening on bash.

Love all the plugins and things like oh-my-zsh, though.

Maybe I'm just not enough of a 'power user,' but I've been using Zsh since 2008 ~ 2009, and I rarely encounter the command-correction. The couple of times I've had it invoked were times where it correctly fixed a typo.

It does fix typos for me too, but most of the time asks weird things like, I typed 'aptitude' did I mean '.aptitude'? It loves misinterpreting some of my commands as dotfiles. Huh?

Then again I have a knack for unintentionally breaking computers, so maybe I've done something in env or rc that's messed it up...

Using the following got rid of a lot of my correction woes:

    alias sudo="nocorrect sudo"

That is why you were getting the .aptitude one, you can use it for other commands that it gets the corrections wrong often.

I've since moved to vanilla bash+bash completion since it is everywhere and zsh completion seemed to annoy me more than help me.

Awesome, thank you!

I don't use them. But there are similar stupid features in bash which I also don't use. Configuring a shell seems normal to me.

I prefer not to configure much, the more I configure on my system, the harder it's to use another system (although, just using vim makes this hard on non-vim text editors.) Although I do find bash-completion handy in many situations (mainly for sub-commands), for mplayer it refuses to tab-complete videos not ending in a proper extension, which is rather annoying.

Don't get me wrong though, bash does have its bad points.

I like process substitution feature in zsh. In bash you can write:

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 ]

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.

But in zsh you can write

vimdiff =(ls /bin) =(ls /usr/bin)

and this will create temporary normal files, instead of just pipes, and vimdiff will work fine.

Holy cannoli, that's an awesome trick. I've always created temporary files manually then diffed, then deleted them.

That seems like a good reason for switching to zsh!

Actually I use bash for my daily work, so I run zsh from bash:

zsh -c 'vimdiff =(ls /bin) =(ls /usr/bin)'

A couple of similarly useful features, and I'm swtiching to zsh. But now I am too lazy to make proper configuration.

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

  local green="$(tput setaf 2)"
  local reset="$(tput sgr0)"
  export PS1="\[$green\]>>\[$reset\] "

And a multiline prompt, let alone one with right-justified elements, is pretty gruesome to me.

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.

zsh spellcheck is very annoying, thankfully it can be disabled. This is my preferred spellcheck solution ;^) https://github.com/mtoyoda/sl

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).

Bash isn't really "minimalist" compared to the likes of dash or mksh. [rob-pike]Completion is a compromise, the Unix Way is to make your commands short and simple enough that you can memorize them all![/rob-pike]

  local green="$(tput setaf 2)"
  local reset="$(tput sgr0)"
  export PS1="\[$green\]>>\[$reset\] "

Could be this in zsh:

  export PS1="%{%F{green}%}>>%{%f%} "

- %{%} replace \[\] - %F{color} sets the foreground colour - %f resets the foreground colour

I would go with something like:

  export PS1="%{%(?.%F{green}.%F{red})%}>>%{%f%} "

It will be green if the last command exiting successfully, otherwise it will be red.

There's also better history support (from my zsh config):

  # History
  # ~~~~~~~

  HISTSIZE=1000
  SAVEHIST=1000
  HISTFILE=$HOME/.zsh_history

  setopt SHARE_HISTORY        # Share history across sessions
  setopt HIST_IGNORE_SPACE    # commands starting w/ a space don't go into history

  # SHARE_HISTORY seems to imply both of these, at least that's how the manpage
  #   reads, so let's comment them out for now.
  #
  # setopt INC_APPEND_HISTORY   # Incrementally append history to file
  # setopt EXTENDED_HISTORY     # Save the timestamp and duration of commands to history file

Actually, except the `SHARE_HISTORY` option (which can be emulated), everything else is available in Bash.

Sorry, I just copy-pasted the whole thing. I know that most of the other options are available, though I didn't know that the HIST_IGNORE_SPACE was available in bash.

In bash you'd use HISTCONTROL=ignorespace

According to the manpage, ignorespace doesn't treat multi-line commands very nicely.

You would have to disable the cmdhist option for that to matter:

  shopt -u cmdhist

Or I guess be working with a bash old enough to not support cmdhist.

Actually, I just tried the foreground/background stuff (similar to yours, but my own code, slightly different) and it works fine in bash 4.

I'm unclear what you mean by foreground/background stuff. I'm looking at the manpage for bash 4.2, and I don't see any short-hand for the color escape codes in prompts.

The spellcheck isn't even on by default.

The article with Knuth's program and Doug's reply is: http://dl.acm.org/citation.cfm?id=315654&CFID=329016541&... (Don't have a non-paywall version.)

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.

Doug's criticism and comparison of Knuth's solution vs. his own is insightful worth reading.

Problem is zsh is not omnipresent like bash is. I'm sure that if you use zsh you also use Plan 9, code in D, write LuaTeX in Emacs and wear a monocle.

Some of these things exist in bash too. For example, newer versions of bash support the recursive glob.

    shopt -s globstar
    rm **/*.swp

I use zsh on ubuntu, write code in ruby and java in sublime text. Your strawman non-argument has no place on HN

Only half his argument is a strawman. He's still correct that zsh is not omnipresent in the way that bash is, and therefore being proficient in bash is still very useful, regardless of the increase in productivity that putting the time into learning zsh would bring.

Both arguments are not sound though, and as a result demonstrably irrelevant. The title of the thread and the argument in the GP is based on features present in ZSH but not Bash and the benefits there of.

The OP's first argument is: for all operating systems Bash exists. Which, while also untrue is and unrelated to whether ZSH has features or improvements that Bash does not. OP's second argument is: all ZSH users also program in D...., which I won't even bother with.

For what it is worth, I use both Bash and ZSH. Their usage and knowledge there of is not mutually exclusive. The only issue I've encountered with using ZSH is that most build scripts expect to be ran from Bash and will run into issues when that is not the case sometimes, so I open Bash before running the command if I happen to be in ZSH at the time.

If I based my tool choices on popularity instead of their appropriateness for the problem domain my work flow would look much different as well.

I don't get your point. I use zsh+oh-my-zsh, and I don't know what Plan 9 is, don't code in D, never used LuaTeX (esp. not in Emacs), and I don't happen to wear a monocle.

In fact I find zsh much easier for beginners and people who don't master the arcane intricacies of *nix.

I -think- the (albiet, overly exaggerated) point is that if you only know zsh, you could potentially be at a disadvantage if you need to use someone else's terminal. Especially a remote server.

zsh is mostly a superset of bash. you will get by.

Might be the case for some, but I don't have such problems.

The problem is when you visit a customer using a commercial UNIX system with System V compatible commands like sh and vi.

I always have fun to see junior guys trying their way around such systems.

These days, I use Zsh on OpenBSD.

I don't use Plan 9, code in D or write LuaTeX, but I do use Emacs and wear a monocle. The last two are not a coincidence as the first (arguably more adequate substitute for God), invariably leads to the latter, most excellent eye wear.

And a note to my Mac friends : "Using csh is like trying to type with your feets[sic] (if you're used to zsh or ksh)."

http://forums.bsdnexus.com/viewtopic.php?pid=177#p177

Bash has been the default shell since OS X 10.3 in 2003.

And since then I keep going back to zsh. :)

Linux/UNIX is not omnipresent. Better use Windows?!

You should use different software or customizations when it's a good trade-off, not because everyone else is or isn't doing it.

> Problem is zsh is not omnipresent like bash is

I don't think it's that much of a problem. My local machine is zsh, my linux servers run bash, my solaris hosts csh. Where ever I am, I just adjust to the local environment.

I am actually frightened how accurate you describe me. Do I know you?

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.

For example:

    setopt extglob
    cd *(<tab>
    ~~ massive spam of possible glob qualifiers ~~

and it works for variable expansion modifiers as well:

    print ${(<tab>
    ~~ completion candidates for parameter flags ~~
    print ${<tab>
    ~~ complete any currently set variable in the current env~~

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.

    vared path

    vared PATH

to see the difference.

    print -l $path # much easier to read

I see your zsh and I raise you fish: http://ridiculousfish.com/shell/

Try it. It's better.

> It's better.

What's "better" about it?

It's got all the zsh features and doesn't need 4 seconds to start, like zsh did for me with oh-my-zsh.

Oh-my-zsh is responsible for being slow as hell. If you really want plugins, Prezto probably still has what you want and is significantly faster on startup. (In my experience, with very minimal customization.)

Well, in the end I realized I had customized it to look and work exactly like fish, so I switched to fish.

1) A pretty great experience even before you start customizing. I only add a git status section to my status line and set some environment variables in my config.fish file.

2) An effort to clean up and orthogonalize shell syntax. The potential portability means I usually still make bash scripts when I'm sharing for others, but for my own stuff it's great.

3) Suggested completions. I start typing a command and if it's one I've used before in that directory it appears in faint gray letters on my command line and I just have to press ctrl-f to bring it up that way.

4) Probably a consequence of (1), but it feels very fast to me compared to when I used zsh. The author also talks about using threads and minimizing disk access to speed it up, but I don't really know how it compares to zsh on that level.

Regarding #3, you can also just press right arrow.

I don't care about experience before I start customizing because I am very certain that I will want to customize. A smaller configuration file does not benefit me at all.

I don't find zsh to be slow even on an older machine, so I'm puzzled what you mean by that.

Which only leaves the suggestion feature, which is interesting but not enough for me to pick up yet another shell with syntax that is even more different from the rest.

I do love the tagline "_Finally, a command line shell for the 90s_".

I was happy enough sticking to bash as it's the default shell everywhere, but since someone switched me to Zsh (using oh-my-zsh) I probably rely on the features too much to ever go back. I also hear https://github.com/sorin-ionescu/prezto is a nicer, cleaner fork of oh-my-zsh but I haven't so found the overwhelming desire to go through the switching pains.

The entire site seems to have that tagline through it as a running joke. I also thoroughly enjoy it.

"Watch out, Netscape Navigator 4.0!" and so on.

I use fish. It's pretty fun to use. It has some pain points (most notably missing things like subshells and inline variable exporting) but it's in beta, so we'll see where it goes. I love the completions though, and it's definitely worth checking out for those alone.

The subshell syntax is there, it just looks different. Instead of: echo `mycmd`. It's echo (mycmd).

I think you're getting your terminology mixed up: the bash man page calls what you described command substitution. Launching a subshell is something different and in bash it is done with parenthesis.

I tried fish for a while, and it's really great. The out of the box experience is way better than zsh and bash. But I switched to zsh, mostly because I couldn't get used to the different syntax.

I just tried fish, way too slow. I held down the backspace key, and instead of deleting 10 characters, the entire line was gone. zsh is also too slow. bash may not have the bells and whistles, but it's at least super fast and doesn't get in your way.

i just tried fish. out of the box experience is great. not digging much yet but so far, so good. much faster start up time than zsh. this is 2013 already and i seriously dont' want a shell takes up a second or 2 to fire up.

I use zsh on my low-spec netbook and have not noticed slow startup times for my shell. That said, I do have a minimalist setup.

    FreeBSD
    DWM
    dmenu

that's probably because i use zsh with prezto (a fork of oh my zsh)

I just tried fish and after half a minute declared it too slow: it is slow to complete (and not very good) and slow to print (or maybe slow to glob: "ls " takes far more time in fish than in bash or zsh).

I do not know if it has all I love in zsh (things like (.) or (om^/) or * or !$), but I would not trade zsh's completion for gaining 10% on startup time.

Current fish author here. Thanks for giving fish a try! I hope you tested a 2.0 branch build, and not the 1.x train from 2009 - a lot has changed since then, including major performance improvements. Check $FISH_VERSION if you are unsure.

'ls' is slower on fish because it passes the -G ("colorize”) flag to /bin/ls, which gives you nice colors, but requires a stat of each file to determine its type. If you want faster but uncolored output, you could redefine the ls function to invoke the ls command with no arguments:

    alias ls 'command ls'

For other instances of slowness or bad completions, we’d sure appreciate it if you opened an issue on the github page at http://github.com/fish-shell/fish-shell/issues/

I just checked and fish is way slower at 'ls *' than zsh. (zsh was done 2x as fast even with a directory with more than 3x as much stuff in it)

I have also a few other flags set in my zsh aliases that's not in fish.

(Tested with 2.0b2)

fish passes the -G flag to 'ls' by default, which produces colorized output, but stats each file. So fish is actually outputting more information than zsh, and what your test is really measuring is the speed of '/bin/ls' vs '/bin/ls -G'

To compare ls speeds for the same workload, run it directly: /bin/ls. I expect no difference, because it is the same binary.

If you wish to compare globbing speeds, do not use bare ls, which does more work in fish. Instead, invoke the ls binary: '/bin/ls * '. Or better yet, just echo: 'echo *'.

I have ls aliased to 'ls -F -H --color=yes --group-directories-first', so no.

('/bin/ls *' is just as fast with '--color=yes' for me btw)

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.

Just using zsh as a drop-in replacement for bash is pointless. You'd need to discover its features and customize it to get added value.

As a simple example, in bash if you use tab completion and there are multiple options, pressing tab again just reminds you that there are multiple options accompanied by a passive aggressive beep (it used to be this way at least). zsh lets you cycle through the possible completions.

> As a simple example, in bash if you use tab completion and there are multiple options, pressing tab again just reminds you that there are multiple options accompanied by a passive aggressive beep

This should fix it in bash: bind '"\t":menu-complete'

Path replacement is also possible in bash, as in:

    cd site1 site2

if you just add this line to your ~/.bashrc:

    function cd() { if [ $# -eq 2 ]; then builtin cd ${PWD/$1/$2}; else builtin cd $1; fi }

that way all zsh functionality is "possible" if you write those functions.

There's no equivalent for the nifty tab completion where you can navigate around though. That's one of the few things I envy from zsh as a bash user.

A cleaner version:

^site1^site2

This will only work if cd is your last command, whereas the zsh version always works.

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:

"git co br<tab>"

It finishes with:

"git co origin/branch"

Whereas what I want is:

"git co branch"

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.

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 that much better than other shells.

Not to mention that it sometimes gets super slow for no apparent reason.. which lead me to turn it off.

Only through zsh did I find out about tab auto-complete.

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.

I still use zsh, though.

For a while bash autocomplete was around, but you had to know to source it from /etc, which seems dumb. Now this stuff is sourced automatically[1].

[1] And sometimes they use it as a 'cheat.' virtualenvwrapper (on Ubuntu, and I assume Debain) is dropped into /etc/bash_completion.d/ instead of somewhere in $PATH. Meaning that it's auto-sourced for bash users, but zsh users need to know where it is, and source it. It seems stupid to put it in the bash_completion directory. Sure it has some completion stuff in it, but the bulk (and purpose) of the file is to setup a bunch of wrapper shell functions. It's like they didn't have a formal place to put it so they just jammed it somewhere.

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.

Tab auto completion takes a second or two (even for files).

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.

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.

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.

You could put "echo" marks all over your .zshrc file to figure out which parts are taking the longest to execute.

I moved from OMZ to Prezto for this reason (its a fork of oh my). But prezto is slow too.

The only recourse I think is to go back to a clean zsh and build your own .zshrc. There are other leaner zsh "frameworks"[1] I have read of, but i intend going back to stock zsh soon.

1) - see zshuery and zsh-m on github.

just use antigen instead of omz - it can use any plugin from omz but seems to be a bit more lightweight

> 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.

Clean the history file.

If you like zsh don't go back to bash, just ditch oh-my-zsh and roll your own config gradually, or try prezto (oh-my-zsh fork which pays attention to performance).

First of all stop using OMZ, it's a massive slow-down. Secondly use the git prompt that comes with git instead, there's no reason to use a custom one.

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.

> I don't want to use zsh specific features in my scripts

How is this a worry?

The topline in your bash script is '#!/bin/bash'

Which tells the system 'run this with bash'.

Well I think there are if statements, loop conditions, and wildcard expansion that works in zsh but not in bash. So you could get used to something working in zsh, then you write an sh script with that thing, and then it doesn't work, and you have no idea why.

Example, I _think_ / (recursive globbing) works by default in zsh but not in bash. If you have / in a bash script without setting the right options then your script won't work and you will have no idea why until you've wasted a lot of time debugging.

When you insert this in the first line of your script

    #!/bin/bash

The specified program is run. From that point on, the bits you're executing in that script are 'bash' no matter what the shell you called it from is.

I've been running zsh on my local system, and happily writing [bash, csh, perl, ruby] using this trick.

The killer feature to me is scp completion, e.g.

  scp someuser@someserver:<tab>

… will ssh into the server, fetch the file list and offer it for completion locally (granted you have set up public key authentication)

my bash does this...

bash does this.

Turn on bash autocompletition and bash does this perfectly.

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.

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.

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.

I have yet to find a useful feature that I don't already get in bash (assuming you are capable of sudo apt-get install bash-completion).

Fish (that I don't use regularly), however, has useful features.

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"

     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

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.

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.

Just use pkill.

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.

The site1 site2 substitution slide is at best disingenuous; I believe in bash you could type

^site1^site2

and get the same result.

Not at all. ^site1^site2 would only work if it was your last command.

The idea, I believe, is when your browsing around multiple versions of the same directory structure. The 'cd site1 site2' allows you to jump directly to the equivalent directory in the other structure.

The equivalent in bash would be something like: cd `pwd | sed 's/tmp1/tmp2/'`

In bash: cd ${PWD/foo/bar}

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.

My own http://imgur.com/6LCS1cj

Hmm doesn't work for me, is it an option you need to turn on?

It's a normal variable, not one set by `setopt`. The following should make commands that take longer than 1 second be reported:

    export REPORTTIME=1

As randuser points out it's an environment variable. There's another one called TIMEFMT which lets you format the output.

Some examples: https://github.com/search?q=TIMEFMT+extension%3Azshrc&ty...

This is super cool... been using zsh for a while and wasn't aware!

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.

She sells 'zed' shells by the sea shore?

Oh, wait. Right. Lost in pronunciation. :P

I really enjoy the regex completion.

Example: $ rm * .gch dir/* .gch

<tab>

$ rm file1.gch file2.gch file3.gch file4.gch dir/file5.gch

I really enjoy it when I'm removing something sensitive and just want to make sure.

In bash, you can use 'C-M-e' to expand just like the shell.

Bah! Give me Ksh.

I much prefer ksh myself, in particular for scripting. Fun fact about how bash is broken:

  export a=0
  cat $file | while read line
  do
    a=$(expr $a + 1)
  done

Bash will fork the while loop as a separate process, inheriting (copying) its own environment, and the variable will only update locally, not in the parent process.

I thought every shell that is sh compatible would fork a while, and a for loop, as a matter of fact any loop into a sepearate process.

This comment however reminds me of some behaviour of bash 2.03 or earlier, where this behaviour was flawed, if you suddenly changed execution path during a recursion in a shell script. Sorry I can't describe it better, and that bash version, that was before 2.03 is long gone now!

Isn't the issue the pipe, not while?

  export a=0
  while read line ; do
    a=$(expr $a + 1)
  done < $file
  echo $a

(Some old shells fork on < but bash isn't one of them).

I think the pipe was the issue.

Nice to know that bash doesn't fork loops that are being used with redirection, and not piping!

save a kitten =)

I switched back from zsh to 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.

I don't know what those are, but why not start them with a bash script, that you launch from zsh?

They're designed to mess around with your shell variables and environment to virtualize an environment for ruby or python. Unfortunately, they're not totally compatible with my customized zsh setup, and I don't have the time to rebuild and test a zshrc from scratch. Launching bash with them would be moot since I'd just have to spend my time in bash anyways, then.

Ah! Thanks.

I don't know about rbenv, but virtualenv works perfectly with zsh o.O

Does zsh have bash's ESC+.?

Yes. Not only that but it has something even cooler: ESC + Q

Let's say you are about to finish a really long command and realize you should have done one other command first.

ESC + Q clears the current line, lets you enter a command, and then inserts the cleared line again on the next prompt. You have to try it to realize how cool it is.

> Yes. Not only that but it has something even cooler: ESC + Q

ESC+. does not work for me with zsh.

zsh 4.3.11 (i386-apple-darwin12.0)

Maybe it's the version.

ESC+Q also doesn't clear the line.

At the same time, the OP links slide deck fails for me at the cd /u/lo/b part. It simply doesn't work.

I can only confirm it works on zsh 5.0 on Ubuntu. And the /u/lo/b expansion works as well.

You probably didn't turn it on when you ran the config wizard thingy.

What config wizard thingy?

I figured this was a default setting.

I use Alt+# in bash to do something similar. It comments out the current line and gives you a new prompt. Then you can run whatever you wanted to do first, and then scroll up, delete the hash sign and hit Enter.

Esc-Q sounds easier, though.

yes, bash is great except it's not default sh.

lolwut

Bash is the gnu shell which is a superset not posix which is basic no frills mixture of minimal ksh and bourne syntax.

BSD has the almquist shell as it's /bin/sh and tcsh as it's /bin/csh. Various commercial vendors licensed the korn shell from bell labs. The korn shell is public domain and open for 13 years now. The default sh on most UNIX boxes are either ash or a hard link to ksh which emulates the POSIX definition of sh. zsh and bash also provide the option to hard or soft link so depending on your distro you may have /bin/sh linked to bash.

Debian at one point repackaged the BSD almquist shell as their system sh calling it dash mainly for speed and stability. I believe they removed it as their programmers apparently couldn't program system level scripts without their non portable bashisms or maybe just one of the NIH moments where everything must live under a single mono-cultural license and identity.

Not quite sure how this is relevant. I was referring to how his/her comment didn't make sense in the context of this post.

(about Debian use of dash) > I believe they removed it ...

No, /bin/sh still points to dash in the latest and just released Debian stable (Wheezy). It seems to me that this transition was already completed in Sequeeze but I haven't checked.

And in many places bash isn't the default shell either.

Reply on news.ycombinator.com