Hacker News Reader

Comment by jerhinesmith | Hacker News Reader

I've wanted to try zsh for a long time now, but I worry about the mental context switching I'll have to do when developing locally and then ssh'ing into another server to perform other tasks (servers, I should add, where I can't install zsh).

Is anyone in a similar situation? If you switched, was it worth it?

View on HN

I switched cold turkey from bash to zsh a few months ago, and going back to bash on servers hasn't been a problem. In my experience, if you've used bash for a long time you don't forget it.

Minor tip - you can use the same .aliases file for both shells, I just source it in .bashrc and .zshrc on my dev machine. So if I ever need to switch to bash for some reason, my most used aliases are still available.

If you switch, don't forget oh-my-zsh [1].

1. https://github.com/robbyrussell/oh-my-zsh

I'm actually not very taken with oh-my-zsh. It seems to add a layer of complexity while not really adding anything you couldn't just paste into your .zshrc. If it eliminated tinkering overhead that would be one thing, but in my experience it just gave me a new layer of software that needed tinkering.

It's along similar lines to copying someone else's rc file willy hilly, without understanding what you're getting. Extra layer of quirks and features that you need to figure out, on top of the already existing layer.

zsh can mostly be thought of as a collection of enhancements to bash, so I find that rather than changing my thought process, I just try to use a zsh feature, realize it's not working, and do it the crummy bash way instead. If a feature exists in bash, the zsh syntax is usually identical.

Also just for the record zsh is installed by default on many OSes, including OSX, so you might be surprised to learn that some of your servers already have it.

I've been on zsh for ages, and the thing that always kills me dead when stuck in bash is the terrible default command line editor. Whereas in zsh, if I go back to edit a multi-line loop or something, it preserves the white-space, bash by default presents the commands as a semicolon delimited list on one line. That's ass. Is there a handy bash shortcut to mimic zsh's behavior here?

How I wish there was a better language for interacting with Unix command line utilities than the godawful POSIXy shells.

Try Tom Duff's rc shell: http://rc.cat-v.org

Is available on *nix systems as part of Plan 9 from User Space: http://plan9.us

Interesting. I'll give it a go.

I've tried living in iPython and eshell, and while I prefer python or lisp as a programming language to almost anything, neither is nearly as quick and dirty as sh for doing stuff with stdin/out from a pipeline of tools. I don't quite know what a better language than sh would look like, but a man can dream.

Also, universe, if you're going to get on fixing the sh problem, can we restructure how the shell operates entirely? Don't do argument expansion! This is one area where the Unix Haters got it really right.

Please define "argument expansion".

In many (all?) unix shells, globs are expanded by the shell before being passed to the program.

   'ls *.jpg'

is passed expanded to 'ls 1.jpg 2.jpg 3.jpg' BEFORE ls is run. This choice means that if a program wants to use another style of regular expression (ie: pcre), it must be enclosed in quotes on the shell, ie:

  "ls | grep -P '.*jpg'"

Yes, that's globbing, but I was wondering what the OP meant by argument expansion. It could be just globbing, or include globbing but extend to variable expansion, braces, command substitution... It's hard to put a case that having the shell do these things is the right way to do it without understanding the OP's point clearly.

Minor point: if the glob doesn't match it isn't expanded. Sometimes useful. I rarely escape scp commands for instance.

See `failglob' elsewhere on this page. What you suggest is sometimes useful but also sometimes wrong and hard to spot because the glob might match locally and one not realise.