
How zsh is more useful than bash - siamore
http://www.slideshare.net/jaguardesignstudio/why-zsh-is-cooler-than-your-shell-16194692
======
Legion
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.

~~~
msoad
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

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

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

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

~~~
pyre

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

------
keeperofdakeys
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?

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

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

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

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

~~~
SkyMarshal
Awesome, thank you!

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

~~~
McUsr
That seems like a good reason for switching to zsh!

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

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

~~~
pyre

      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

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

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

~~~
mnarayan01
In bash you'd use HISTCONTROL=ignorespace

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

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

------
jcrites
The article with Knuth's program and Doug's reply is:
[http://dl.acm.org/citation.cfm?id=315654&CFID=329016541&...](http://dl.acm.org/citation.cfm?id=315654&CFID=329016541&CFTOKEN=58713819)
(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.

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

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

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

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

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

vs

    
    
        vared PATH
    

to see the difference.

    
    
        print -l $path # much easier to read

------
StavrosK
I see your zsh and I raise you fish: <http://ridiculousfish.com/shell/>

Try it. It's better.

~~~
beaumartinez
> It's better.

What's "better" about it?

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

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

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

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

~~~
bashaintthatbad
> 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'

------
shared4you
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 }

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

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

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

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

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

~~~
pyre
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._

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

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

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

~~~
bdunbar
> 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'.

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

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

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

~~~
andyhmltn
Turn on bash autocompletition and bash does this perfectly.

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

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

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

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

~~~
bashaintthatbad
Just use pkill.

------
brooksbp
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?

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

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

^site1^site2

and get the same result.

~~~
asdfaoeu
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/'`

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

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

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

~~~
kemist
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...](https://github.com/search?q=TIMEFMT+extension%3Azshrc&type=Code&ref=advsearch&l=)

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

------
tekacs
She sells 'zed' shells by the sea shore?

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

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

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

------
RexRollman
Bah! Give me Ksh.

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

~~~
McUsr
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!

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

~~~
McUsr
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!

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

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

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

~~~
bdunbar
Ah! Thanks.

------
jasonlotito
Does zsh have bash's ESC+.?

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

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

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

~~~
jasonlotito
What config wizard thingy?

I figured this was a default setting.

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

~~~
zachlatta
lolwut

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

~~~
yaantc
(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.

