
Use Zsh - daivd
http://fendrich.se/blog/2012/09/28/no/
======
dbbolton
There's one of these "why you should convert from X to Y" posts every week or
so. I understand that a person can be somewhat excited about finding a better
application to replace their old stand-by and might feel the need to
evangelize. I don't see anything wrong with wanting to introduce others to new
software with a helpful attitude.

However, it seems like all of the bash-to-zsh posts boil down to better
autocompletion and oh-my-zsh. I haven't really seen anything fresh in quite
some time. This is something that I do not understand. Does the author think
he is saying something that hasn't been said, or is the hope that if we keep
saying the same thing over and over that we can get more people to try zsh? I
really can't say.

Also, I recommend _not_ using oh-my-zsh if you are a beginner. Rather, I
recommend that you start with a blank slate and read the documentation. This
is the only way to get the exact configuration you want. If you don't really
care about your shell that much, then why are you switching in the first
place? Alternatively, you might try using the "recommended" config offered on
first run (I can confirm that the default config on Debian is a good start and
will work for most people). Then go through that config while reading the Zsh
User Guide[1] and tweak it to your liking. It is my opinion that oh-my-zsh
ultimately stops people from reading documentation and offers an incentive
(ease of use) for using code that may not be understood (when it probably
should be). However, a lot of people seem to like it. Perhaps I am missing
something.

My intent is not to discourage this author specifically, but rather to call
into question the underlying motivation and behind and utility of all posts of
this type.

1 - <http://zsh.sourceforge.net/Guide/>

~~~
dima55
The killer feature of zsh is not the tab completion but the globbing. Really.

More or less, you never need the 'find' tool when using zsh. For example, if I
want to find all the Makefiles in this or child directories that have the
string 'abc' and have been modified less than 1 hour ago, I can do

    
    
      $ grep -l abc **/Makefile(mh-1)
    

If I want to look at the most-recently-modified file, I can

    
    
      $ less *(om[1])
    

If I have a symlink 'dir' that points to a directory and I want to cd to the
pointed-to directory, I can

    
    
      $ cd dir(:A)
    

Clearly, there are lots of codes, but you don't need to remember them, since
the tab-completion gives you online help. I can type the '(' then press 'tab',
and it'll give me a list of the various codes that can follow and what they
mean. There are tons of others. If I want all

    
    
      *
    

EXCEPT

    
    
      *.h
    

I can use

    
    
      '*~*.h'
    

Or for instance, say I have a directory of photos. I want to pick DSC00095.jpg
through DSC00107.jpg. In bash, you cry; in zsh I say

    
    
      DSC<95-107>.jpg.
    

After I've typed in the glob, I can press 'tab', and it'll expand the glob in-
place, letting me know if the code worked without executing. I can then undo
to get the code back and have it live in my history.

This feature alone is enough to make a switch worthwhile. It did take me an
hour to set up my .zshrc to work like bash, but this has easily paid for
itself.

~~~
lutusp
> Or for instance, say I have a directory of photos. I want to pick
> DSC00095.jpg through DSC00107.jpg. In bash, you cry; in zsh I say
> DSC<95-107>.jpg.

No need to cry -- Bash does it this way:

    
    
       DSC{95..107}.jpg.

~~~
dima55
Ugh... Did you actually try this?

    
    
      dima@fatty:/media/usb/DCIM/100RICOH$ ls R<22399-22402>*
      R0022399.JPG  R0022400.JPG  R0022401.JPG  R0022402.JPG
      dima@fatty:/media/usb/DCIM/100RICOH$ bash -c 'ls R {22392..22402}*'
      ls: cannot access R22399*: No such file or directory
      ls: cannot access R22400*: No such file or directory
      ls: cannot access R22401*: No such file or directory
      ls: cannot access R22402*: No such file or directory
    

Bash seems to treat these as strings, not like numbers. So in this specific
case, I could have manually counted the number of 0s that are required. In
some other case where the field width wasn't constant, I wouldn't be able to
do that. What if I have files

file.1, file.2, file.3, ..., file.9, file.10, file.11, ...

How do I pick 9-11 in bash? The point is zsh has features that are a real
productivity boost. It's certainly arguable whether a switch is worthwhile,
but claiming that these features are just "cosmetic" is wrong.

~~~
pyre

      > How do I pick 9-11 in bash?
    

Like so:

    
    
      file.{9..11}
    

I think that you mean for the files to be numbered like:

    
    
      file.009
      file.010
      file.011
    

Bash would try to expand:

    
    
      file.{9..11}   => file.9   file.10.  file.11
      file.0{9..11}  => file.09  file.010  file.011
      file.00{9..11} => file.009 file.0010 file.0011
    

Neither would match all files.

~~~
dredmorbius

        echo file.0{09..11}
        file.009 file.010 file.011

------
fusiongyro
I used to use zsh but switched back to bash a couple years ago simply because
the benefit wasn't worth the trouble. When I first changed back I went to some
difficulty to get my PS1 to have color in it. That slowly faded away and now I
have a visceral, negative reaction to prompts with that much colorful whizzy
fu. Maybe in a few more years I'll trim out the username/hostname/path and
become content with just a %.

~~~
slurgfest
It faded away because it was too difficult to get the prompt working?

~~~
fusiongyro
When you have access to a lot of machines run by different organizations but
not administration privileges on most of them, it's a hassle.

~~~
benvd
So put your zsh config in a git repo, clone it wherever you need it and
symlink to the repo?

~~~
fusiongyro
Uh huh. Now I have to install git on all those computers as well as make sure
there's a recent-enough copy of zsh. Much less work that way.

Or I can just use the bash that's already there.

~~~
oinksoft
Your concern about git however is unrelated to shell choice. I customize bash
quite a bit (my own completions, etc.) and maintain dotfiles in a git
repository. I have a post-receive hook that tars up my dotfiles and puts them
at a public location on my http server that only I know about so that I can
easily get them when I'm on a machine without git. I'm not going to do that
for every machine, but if I'm stuck debugging something on some odd machine,
at the very last I want my vim settings around.

~~~
fusiongyro
It makes more sense for vim than zsh though. What color your prompt is has a
lot less bearing on your productivity than your editor configuration. (Though
I don't do much of that either).

------
sstephenson
Here's another perspective: <http://sstephenson.us/posts/on-configuration>

~~~
Apreche
I independently wrote pretty much the same post.

[http://www.apreche.net/dont-change-the-computer-change-
yours...](http://www.apreche.net/dont-change-the-computer-change-yourself/)

~~~
darkstalker
Probably you used Linux at the time it wasn't very mature. I'm running Gentoo
now and never had to reinstall to fix things. With modern computers compiling
is very fast, most software compiles in less than a minute. I spend more time
solving binary compatibility problems with CentOS (at work) than compiling
stuff via portage.

I recently bought a new video card (nvidia), plugged it and then booted linux.
It just worked out of the box. Then I proceeded to boot windows, it started on
a low resolution video mode because the current driver failed. So had to
download and install latest drivers manually. The whole procedure took like 3
or 4 restarts.

~~~
shazow
That's the huge advantage of distros without discrete upgrade paths. I have
the same Gentoo install on my desktop since I built it in 2008. Meanwhile I
tried Ubuntu on my laptop for a couple of years and every time a new version
came out, I tried to upgrade only to find my system borked, hours wasted, and
ultimately my giving up and doing a fresh reinstall.

And yes, so many more things work "out of the box" today than ever before (as
long as it isn't ATI/AMD :P). The Linux ecosystem has grown and improved
incredibly over the last few years. I wouldn't dare argue whether it's better
than OSX or Windows, but I can comfortably say that it has advanced a much
further distance in the last few years.

------
redsymbol
I've been using zsh for over ten years. Since one of my best friends (now a
computational physicist) convinced me to try it in college.

Over time I've temporarily switched to others just to make sure I wasn't being
stuck in a rut, but I always have come back to zsh. It's a joy to use as a day
to day command line interface.

For writing shell scripts, i.e. actual software implemented in shell, I
actually prefer bash. In large part because it's more portable, in the sense
that any given machine is likely to have bash already installed.

~~~
dbbolton
If you really want your scripts to be portable, you should probably write them
in POSIX sh. There might be a high probability that any given machine with a
Unix-like operating system will have bash installed, but it is essentially
guaranteed that it will have sh.

However, if a person really wants to run your scripts, he can probably install
the interpreter for which they were written.

So choosing bash as some sort of middle-ground isn't really justifiable.

~~~
goldfeld
When it probably covers mostly all computers that will run your script, I
don't see why it isn't a good compromise.

------
MatthewPhillips
This article really feels like bikeshedding to me. I'm always going to use
whatever shell comes default with the OS I'm on (which almost always means
Bash), simply because changing the shell is an unnecessary block of time that
could instead be used writing software. I need a _really_ good reason to
switch, something the equivalent of pipes, and if the #1 reason you can give
is "Powerful context based tab completion", I'm confident in dismissing zsh as
a cosmetic improvement on bash that I don't need to waste my time on.

~~~
darkstalker
zsh's tab completion is definitely not cosmetic. It can do very useful things
like completing scp destination paths over remote hosts.

~~~
ithcy2
This has been done by bash_completion for years.

------
ludwigvan
> In Bash, we often use PgUp to search through the command history. In Zsh you
> just write part of the command and press Up. This will let you cycle through
> all command lines that contain what you have written, not just those that
> begins with it. If you don’t write anything Up works as usual, by cycling
> through all commands.

This is not true, you can do that in Bash too (via .inputrc)
[http://blog.theliuy.com/2011/inputrc-keyboard-mapping-
config...](http://blog.theliuy.com/2011/inputrc-keyboard-mapping-config-file/)

Edit: Maybe I misunderstood though, does pressing Up really let you search all
command lines that contain what you have written, not just those that begins
with it? It doesn't seem to do that on my zsh.

~~~
bryanlarsen
In bash, I press ctrl-r and then enter part of the command. additional
ctrl-r's cycle.

~~~
bostonvaulter2
Zsh does that as well with the same exact shortcut

------
eblume
I tried using oh-my-zsh, but all of a sudden bringing up a new terminal (on OS
X) went from taking ~1 second to ~5 seconds. Totally killed my interest in
zsh.

I'm sure there's a way to make it all work nicely, but bash has been doing
just fine for me, I don't feel the need to figure out an entirely new
configuration system for a tool that ultimately has little new utility in my
workflow.

~~~
osdf
There is a cleaner 'version' (==fork) of oh-my-zsh that fixed the long startup
time for me: <https://github.com/sorin-ionescu/prezto>. With nice, fast setup
(overwrites your .zshrc file!) and lots of documentation.

~~~
crazydiamond
Thanks, I have the same slow startup issue with oh-my-zsh. But the link does
not talk about how to migrate from oh-my-zsh to prezto.

Which files should I copy over, or compare and update once I install prezto ?

------
zobzu
So I heard "use zsh its so cool" since about 12 years, every 3 month. Here's
the new post, just in time.

Don't get me wrong, I use zsh. I also use bash. I end up using more bash than
zsh though. The reason are the same as 12 years ago. If zsh was the most
popular shell _right_ _now_ the same people would be praising bash.

\- they're equally fast for what we need them to do

\- they've similar features

\- bash is _everywhere_

\- bash is _the_ standard for all scripts

\- zsh has extra complexity

Oh yeah and stop using pg-up in bash, use ctrl-r. And if different is cool, I
don't know, use fish.

------
mathieuh
Any one else using Fish?

~~~
nagisa
Me. Just came to tell, that it's even better than zsh, but ultimately it's a
matter of preference.

~~~
slurgfest
What are your top reasons to use fish over zsh? (Bearing in mind, of course,
that it's ultimately a matter of preference...)

~~~
shadowfiend
Syntax. I much prefer the fish syntax, even though the fact that it's
different from bash can occasionally cause headaches. When I'm mucking with my
shell, I'd rather not be remembering [[ -z ]], because I don't do it often.

Basically most shells are designed around power, which is fine. Fish is
designed around ease-of-use, which I consider to be a better idea since
there's already a ton of power in the UNIX tools that are on the system.
That's not to say fish isn't powerful, mind you. Just that you detect a
different emphasis when using it.

Consider setting colors in a prompt, for example. zsh and bash use
PS1=$'\e[0;31m$ \e[0m'. Ouch. More recent versions of zsh do let you do
PS1="%{$fg[red]%}%n" type stuff, I'll confess.

For fish, setting up a colored prompt or whatever:

    
    
      function fish_prompt -d "Write out the prompt"
        printf '%s%s@%s%s' (set_color brown) (whoami) (hostname|cut -d . -f 1) (set_color normal) 
    
        # Color writeable dirs green, read-only dirs red 
        printf ' %s%s' (set_color green) (prompt_pwd)
    
        # Print git branch
        if test -d ".git"
          printf ' %s%s/%s' (set_color normal) (set_color blue) (parse_git_branch)
        end 
        printf '%s> ' (set_color normal)
      end
    

It's stuff you already know how to do. It's not an environment variable, it's
a function. Commands you use normally. Invoking other regular fish
functions/commands. Etc etc. It just feels cleaner (to me).

~~~
slurgfest
Ah, so a lot of it is that you like the config language better! That would not
have occurred to me. Thank you for your reply.

~~~
cutie
The biggest draw of fish is the syntax highlighting at the command line. I
still write scripts in bash though.

------
ithcy2
Everything in the "Context based tab completion" paragraph is already done by
bash_completion.

* It knows which commands git takes? Yes. * which hosts are in my hosts file for ssh? Yes. * which users my system have when I write chmod? Yes. * available packages to apt-get? Yes.

Plus everything in /etc/bash_completion, plus the hundreds of additional
commands in /etc/bash_completion.d, plus many, many online resources for
creating your own...

~~~
bjourne
One important difference between how that completion works and zsh's is that
zsh cycles between the available completions if you repeatedly type tab. E.g.
if you have the files [less01.png, less02.png, less03.png] and type "eog
less<tab>" in bash will show you the files. Press tab again and it will list
the files again. In zsh, the second tab press would fill in "less01.png", then
"less02.png" and so on.

It's a matter of preference which completion strategy is the best, yes. :) But
for me I've found that zsh's way to do it saves me many more keystrokes than
bash's way.

~~~
Evbn
That is an inputrc configuration not a shell feature.

[http://stackoverflow.com/questions/7179642/how-can-i-make-
ba...](http://stackoverflow.com/questions/7179642/how-can-i-make-bash-tab-
completion-behave-like-vim-tab-completion)

Yay Unix. Input collection is a pluggabls component.

~~~
bjourne
That almost works. But it seems like you can't have tab to <i>both</i> bring
up a list of completions <i>and</i> cycle through completions which zsh does.

------
lr--rw-rwx
My concern with Zsh is that is just not that much better than Bash and that's
the (valid) reason, why it's not getting widespread adoption.

It's like with Plan9 and Linux or new systems languages which try to make a
better C. The technology _is_ better than the existing one, but not that much
better that it's that relevant.

I think one of the main problems of current shells is that they try to be a
CLI and an interpreter for a programming language (e.g. Bash script) at the
same time, but the user uses mostly just one of these features for certain
periods of time. At one point he wants to control the computer in a very
efficient matter (system usage), so short keystroke sequences are convenient.
At other times one wants to do more complex stuff which involves programming
(development).

However current Shells are at any point in time prepared for both and that's
the reason why both tasks are sometimes cumbersome.

------
Alan01252
Just started using Zsh. I never really had any qualms with bash, and so had
the mantra if it's not broke don't fix it.

Then I worked with a couple of junior developers and noticed them doing some
cool looking things on the terminal.

Suffice to say I've now switched to Zsh and can't see myself going back to
bash any time soon. Thanks junior devs :)

------
scrsh
It's not portable.

And I have to invest time to learn all the codes.

In the times it takes to learn zsh, I could write the same functionality into
small sh scripts which I can run on any machine. Put them in a folder, add it
to my PATH and I'm in business.

I can tar up this folder and upload it to some internet-connected machine so I
can download it to any other machine with an internet connection.

zsh is wonderful. It is the ultimate "interactive" shell. But it's not
portable.

Moreover, the less "interactive" I need to be on the command line the better.
If I have short, portable scripts to do certain things, and I can run them on
any machine with /bin/sh (no need to install anything; sh is the universal
interpreter), that's a nice thing to have. zsh won't give me that.

------
buster
Been trying zsh for a while, ran fish for 1 or 2 years. Am back to bash
because to many scripts rely on bash and wont't work on zsh or fish.

Thing is, it's note that hard to get the mentioned features in bash. Good tab
completion, good git enabled color prompt, ssh completion, host completion,
command completion and (my favorite) "start typing, press up, cycle through
command history with the given input" aka reverse search. I really really
liked fish. But incompatibility with bash was just too annoying after a while.

~~~
jlgreco
I use zsh and write all my ~/bin/ scripts in bash.. what problems did you
encounter? I don't see how issues could possibly even occur.

~~~
buster
You write YOUR scripts in bash, it's not about my scripts though ;)

Also, it's annoying to constantly switch between zsh and bash when you are
working on other servers over 50% of your time.

~~~
jlgreco
I was wondering what you mean by "many scripts rely on bash". If you write a
script in bash it will work from zsh just fine.

I guess I don't really run into the same adoption difficulty other people seem
to, since at work we use zsh instead of bash.

------
djcb
I've been using zsh for a decade or so, and I like it quite a lot. For basic
things, it works enough like bash to hardly notice it; but slowly I've learned
all the special tricks.

Now, I would recommend against using /oh-my-zsh/ and the like wholesale; just
add useful things to your zsh setup step-by-step, where you actually
understand each step.

Otherwise you're just importing a blob of magic that can interact with other
things in weird ways. /oh-my-zsh/ contains a lot of gems, but take them one by
one.

------
nakkiel
I'm not going to elaborate much because I feel I'll waste my and I have a
plane to catch but I have yet to see a compelling argument to make me believe
zsh is in any way superior to bash.

All posts on the subject show that theirs authors have been using a shell they
don't know and have replaced it by another shell plus configuration files made
up by someone more clever. All posts are also bullet lists of features bash
can actually be configured to do.

Someone wake up.

~~~
X6MW3aQrZU5VKkz
That's exactly how I feel about this as well. I can actually confirm that my
bash config does _each_ of these things other than some of the globbing
features (* * for instance does work though).

edit: should be two asterix characters with no whitespace in between, but if I
do this they're not displayed. Any advice on how to get that working?

------
reyan
I use prezto (<https://github.com/sorin-ionescu/prezto> \-- initially a fork
of oh-my-zsh).

~~~
dlisboa
Same here. oh-my-zsh was too slow for me and took away one of the advantages
of zsh (that of being faster to load than bash). Also, a great number of oh-
my-zsh config options are, to me, incredibly annoying (the long completion
menu is the worst shell interface ever invented).

I'm in the process of trimming down prezto to exactly what I need, since it
also has too much fluff. It's a great resource, I'd recommend it to anyone
wanting a slimmer and easier to grok zsh configuration.

------
army
I use zsh for day-to-day use. It's mostly been good to me but sometimes I
contemplate switching back to bash because of the performance: sometimes zsh
simply hangs for seconds at a time. I'm sure one extension or another is at
fault and I could fix the performance issues by reconfiguring things, but I
really don't want to put the time into doing that.

------
brcrth
No, really. Use what you like/know. I hate posts about "you should use X
because I like it".

~~~
notJim
How do you ever learn anything or improve your workflow if you never try new
things?

------
tharris0101
I used zsh for years. Loved it. I just don't do as much command line stuff
anymore so vanilla bash works fine for me. I do miss the history stuff
mentioned at the end of the article, though.

------
adambratt
Been meaning to start using it for a while. You convinced me to download it
and see what all the fuss was over.

Couldn't be happier!

~~~
daivd
Great!

------
zerop
Not sure if this is good ask. But windows needs a tool like this. Why not have
a port for windows as well.

~~~
ithcy2
like cygwin zsh? Or are you talking about oh-my-zsh?

------
grandalf
just installed zsh but now my rvm is broken, any quick tips? tried adding the
following to .zshrc but it doesn't appear to have fixed the issue:

    
    
      if [[ -s "$HOME/.rvm/scripts/rvm" ]] ; then source "$HOME/.rvm/scripts/rvm" ; fi

~~~
jolan
Are you using 1.16.x? The changelog mentions improved zsh support.

<http://www.engineyard.com/blog/2012/rvm-1-16/>

~~~
grandalf
Got it figured out, turns out .rvm/bin ended up in PATH which screwed it up.

------
ta12121
I've never read about zsh on HN before. I swear it officer.

------
y4m4
what a joke!

------
lurker14
As someone who used zsh for a while but got tired of setting it up everywhere
I go and losing the "local community" bash stuff, I humbly request:

someone please post a rebuttal showing how to do all this in bash with
appropriate .bashrc/functions and utility programs like fasd.

~~~
lloeki
In spirit, here's mine [0], where I maintain a configuration that works in a
similar way for _both_ bash and zsh and does not try to make one identical the
other[1]. It respects login vs interactive, and is reasonably fast on start (i
have a few ideas to make it faster).

It's designed to be lean, DRY, simple and modular. You can use it as is,
overwriting you own dotfiles with setup.sh, or you can pick-source each
file/feature you want individually (some need a couple vars set, grep for
_DOTFILES__ ).

It leverages available software but tries not to break when it's not
available. It works under both Linux and OSX.

It includes an implementation of something like vcs_info for bash, leading to
a much more configurable PS1 than git's provided bash prompt support.

Its prompt tries to use colors semantically, and keeps things logical and non-
cluttered.

If this reads like this is the best thing since slice bread, that's because it
is! ... for me. But I'm sure you could find a useful thing or two in there.

[0] <https://github.com/lloeki/dotfiles>

[1] I went all the way to hack support of right prompting and reverse-%
cleanup on non-newlined output in bash. It works well... most of the time, but
when it breaks it's ugly so I just disabled it.

