Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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/



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.


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


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.


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


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


> Neither would match all files.

True, but this works: file.*{9..11}

It globs on the LHS, and requires the RHS to be literally consistent with the generated index.

I had the same problem with my earlier example, and the above is how I worked it out.


  file.{009..011}


> Ugh... Did you actually try this?

Your point is correct -- Bash is treating these as strings. I didn't have your file names so I tried a similar example, and I just realized I have to correct my example. I have a directory of graphic files with embedded numbers with leading zeros, for example 001 to 031. I was able to say:

$ ls geographic_harbor_2012_06_02_*{1..31}.JPG

And get all the members. But it's not the same as your example.


How old is your Bash? GNU bash, version 4.2.37(2)-release produces

  $ ls 
  R1004.jpg  R1006.jpg  R1008.jpg  R1010.jpg  R1012.jpg
  R1005.jpg  R1007.jpg  R1009.jpg  R1011.jpg  R1013.jpg
  $ ls R{1005..1009}*
  R1005.jpg  R1006.jpg  R1007.jpg  R1008.jpg  R1009.jpg


Read the post again. Your case works because you have exactly the right number of digits.


Missed that. Well, Bash does it intuitively however you like:

  $ echo {8..12}
  8 9 10 11 12
  $echo {08..12}
  08 09 10 11 12


zero padding brace expansion has been available since bash version 4 20/02/2009

$ echo {000..10}

000 001 002 003 004 005 006 007 008 009 010


The underlying motivation is to write it specifically for a few people, whose current way of working I know, and who have asked me for some information on zsh. If it were not for them, I would not have written it, since I don't add anything new, just summarize in a different way.

Having written it, though, I thought I might share it. For most people, like me, the timing has to be right to try something new. You have to have the time and the motivation and everything else. By sharing it, I hope to hit some people with the right timing (and based on some comments, upvotes, etc, I know I did).

I must have seen 20 Haskell advocacy posts before I actually tried writing something in it. Same with you for some new technologies?


>I recommend not using oh-my-zsh if you are a beginner I just started started using zsh today, and decided to go with oh-my-zsh instead. zsh is FAR too much configuration to go through to be worth the utility for me. On the other hand, with oh-my-zsh, it took me a few minutes to get a beautiful theme, a bunch of neat plugins (history-substring-search and jump are my favorites right now) and also exposed me to the solarized theme on vim (through a zsh theme that required it).

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

I'm diametrically opposed to this philosophy. Every time I start out trying to do something perfect or the "right way", I lose interest or time to continue. On the other hand, now that I used oh-my-zsh and it gave me all these awesome features in 10 minutes, I'll be motivated to continue learning about zsh over time.

Not to say that you're wrong and I'm right, just offering a counterpoint.


This conflict looks succinctly like bottom up vs top down thinking. Neither is more correct.


The question, however, is how did you come to this conclusion? Was it via bottom up or top down thinking?


I read HN religiously (perhaps too much so), and I am absolutely interested in bash vs zsh - and this is the first time I've read an article on the topic.

Never heard of oh-my-zsh before. Loved the post.


I agree wholeheartedly, oh-my-zsh is usually recommended to beginners with zsh, but I've always found that to be a mistake.

If you don't understand what zsh can do, how do you expect to take advantage of a highly specialized pre-configuration?


> better autocompletion

Bash has context dependent auto completion as well. So what's the advantage of zsh here?


the quote in your post is the answer to your post.

they both have it - zsh's is better


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

http://xkcd.com/974/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: