While from what I have read about it zsh is a nice shell, it doesn't deal with what I find to be the biggest problem with bash, sh, and just about every shell that isn't fish: the horribly ugly and inconsistent syntax. And I think it's rather sad that on what is supposedly the most advanced shell of our generation, you still have to deal with a thousand ridiculous redirections and quoting styles, different delimiter keywords for every control structure ("fi?" "done?" "esac?" Why not just freaking "end?"), and rules for expanding variables that come back to bite you in the rear whenever you have spaces, quote characters, or anything besides a run of letters, numbers, and a select few punctuation marks in your filenames or other variables.
I have been using fish for several years now. It's community is a fraction of zsh, bash, and others, and I've tried to go back to them, mostly out of misplaced "everyone else is doing it" mindset
Fish is a great shell. It's a modern shell, that uses colors, UTF, and processing power that didn't exist when the others were designed. I feel the best thing about it is the sane defaults and large number of prebuilt completions. For any other shell, I have to dive into bashrc's and esoteric commands to get what I want. Fish just does what I want. It's made me far more productive, and for that, it gets my best shell award.
Its scripting support is good, very similar to other shells. Yes, the syntax is non-compatible, and not even POSIX. But, it makes more sense. Besides, for anything except the simplest of scripts, I use lua. I doubt you'd want to use bash to do something very complicated.
Some people want their shell scripts to be compatible and do a lot of cool things. I feel that the days of a shell being used for scripting are past. For me, a shell is a way of interacting with the system. Fish does this really well. Scripting is a slight afterthought, as it should be.
I feel that the days of a shell being used for scripting are past.
I've noticed this attitude among those who tend to use sysadmin-minimizing features of the internet, such as cloud hosting. There's still a whole world of real server out there, though.
I get what you're saying but have to say that since I've started doing more deployments in AWS I'm writing more and more shell scripts. Any given Linux AMI will support Bash and even though shell scripts are painful to write and maintain, doing the equivalent in e.g. Python is painful as well :-(
That is true. I do minimal system administration, so that is not a concern for me.
I tend to use a shell for system interaction more than scripting. In that regard, I give more importance to interactivity enhancements. On the other hand, I have found myself using bash to automate simple things in our company testbed. As soon as I need a datastructure more than an array, or recursive functions, I jump to lua.
If your primary job is to be a sysadmin, then Bash is Required Reading.
I disagree. As a programmer I can represent inputs and outputs as text and write code to do intended transformations. As a quick ad hoc test I can easily knock up a shell pipeline to give confidence in those results, even if it would be too slow for production. There's many occasions when powerful shell usage is quicker to write than Python, etc.
!! is not specific to fish. It is a history feature to get the last command. It's like using '!ec' for getting the last command that starts with 'ec'. Using `!!` is not "getting output of previous command", it is re-executing it and getting that output.
You haven't told me how to do a `!!` in fish. (I do understand that it re-executes the previous command). I am used to using this in other shells like bash and zsh, and would like to know if there's some way of doing it in fish.
AFAIK this is not possible with fish, as variables cannot be used as commands like in bash (and the ! history feature does not exist in fish, it is designed to be fully interactive).
Yes, I just use the builtin's. Basically os.execute, and io.popen.
Popen is not the greatest because you can't get exit statuses from it. But for a quick script that is too messy in shell, it suffices. I believe that there is an extension to lua that has a popen that returns exit statuses. That can be used too.
For pattern matching, I either pipe to perl and capture the output, or use the inbuilt pattern matching system. It's surprisingly powerful.
You can also get the exit status using Lua 5.1 but it's definitely nasty (io.popen('your-command; echo $?') and the last line of output is the exit status).
As long as the people designing fish believe that, it will be unsuitable for people who want or need customized solutions. That describes a lot of people using shells now.
Once you learn the zen of shell script, like any programming language, those problems pretty much go away. Shell script is a tiny language packed with features and can be learned through constant use in a week, but like any language, it takes time to master.
It's incredibly powerful for interactive use and data manipulation combined with the standard Unix tools and sometimes pulling out perl or python is more work than just banging out a pipeline on the command line.
Quoting does take some time, but just remember that when in double to quote your variable expansions with double quotes. There's more too it, but that's a good rule to start with.
One of my favourite aspects of rc is the sane array handling.
In bash: $array expands to the _first_ element of the array; you have to say ${array[@]} to get the whole array. And then you have to quote it in case one of the elements has spaces.
In rc: $array expands to the whole array, and the expansion is _not_ re-parsed, so if an element of the array has spaces in it, it is still considered a single element after the array variable expansion.
For this reason rc doesn't even need double-quoting; it only has single-quoting for escaping spaces in string literals.
The rc example is worse than the first of yours. I hate the zsh special syntax in the second: it violates a deeply ingrained code feel I have about the syntax of shell code. The do ... done syntax helps the eye.
rc really shines when you have problems that in bash or zsh would suggest using multiple layers of expansion. The semantics of rc's expansion is much less thorny.
I prefer real examples - here, why not just write
seq 1 100
- what is the loop for? And shell loops can frequently (always, if you are willing to write helper scripts) be replaced with xargs, which tends to be very much faster, e.g.
seq 1 100 | xargs echo
(which doesn't quite give the same output, but passing -n1 to xargs fixes that)
Honestly, I find that stuff pretty easy to remember. And is it that ugly, in the grand scheme of ugly shell syntax? :)
I mean, what about [[ ]] vs. (( )) vs. [ ]? Or the beginning of a case statement? Those always get me since I don't use them often enough for them to stick.
All of the other syntax is shell-specific (run via built-ins), so that can vary, and be a little more obtuse.
[1] Albiet with some minor differences:
% if [ -d /tmp ]; then echo "TRUE"; fi
TRUE
% if test -d /tmp ]; then echo "TRUE"; fi
test: too many arguments
% if test -d /tmp; then echo "TRUE"; fi
TRUE
% diff /usr/bin/{test,\[}
Binary files /usr/bin/test and /usr/bin/[ differ
% man \[
No manual entry for [
The thing I like about fish is the easy history nav. I type "git" and press Up, and I get to go through my history of anything that started with "git" very quickly. I'll often remember I typed an svn command three weeks ago, but forget the parameters, and I'll have it back within 15 seconds.
the problem is there are really two things that most shells are trying to simultaneously optimize for--interactive and scripted use. sometimes these conflict in annoying ways--i think the main reason arrays are so obnoxious to use in bash is that their syntax collides badly with glob syntax.
some shells that make excellent script languages are terrible for interactive use--a stock ksh, even ksh93, is pure torture for someone who grew up on bash and zsh and expects completion, history, a nice prompt, decent command editing, etc.
(i'm not sure if the reverse is precisely true, though certainly there are interesting programming features in ksh that are absent in zsh--discipline functions and so on.)
I think you're underestimating how frequently some folks do things like:
for x in 'seq 1 100'; do echo "something with $x"; done
(Please forgive lack of backticks on my cellphone keyboard)
Or many variations, like every line in a file, or result of a command piped to sed or awk and then processed. Init scripts are about the only shell scripts I write anymore, but I use frequently use it from the commandline, typically on remote terminals.
I now always use $(cmd) instead of `cmd`. Much easier to read and it fits in better with process substitution <(cmd). More importantly it all nests sanely $(cmd1 $(cmd2)) and works well in quotes "Blah: $(cmd1 $(cmd2))".
- I'm using bash on Ubuntu. When I type "kill <tab>" I get a list of process numbers, not the list of files in my current directory as you imply.
- shared history sounds like a bug, not a feature. I have long lived terminals open, each dedicated to a specific purpose. Shared history would intermingle them.
- typing `gut` in bash gives me:
No command 'gut' found, did you mean:
Command 'cut' from package 'coreutils' (main)
Command 'get' from package 'code-aster-run' (universe)
Command 'gout' from package 'scotch' (universe)
Command 'git' from package 'git' (main)
Command 'gpt' from package 'gpt' (universe)
Command 'gst' from package 'gnu-smalltalk' (universe)
You're batting 0/3. Certainly there must be some advantages to ZSH, but you haven't listed any yet.
(Note that I didn't have to configure any of this. Ubuntu probably did, but I didn't).
2. More importantly, in ZSH if the correction is accepted by the user the command gets executed (with the fix) without any manual redoing. The correction can even be made permanent for frequent typos.
(and while I like ZSH a lot, shared history does tend to be a pain in the ass for me)
How about the fact that zsh enforces that you spend a certain amount of time per day just contemplating your existence:
% time zsh -c exit
zsh -c exit 0.22s user 0.21s system 97% cpu 0.436 total
$ time bash -c exit
bash -c exit 0.00s user 0.00s system 83% cpu 0.004 total
Typing too early will just blackhole your keystrokes, of course, so no cheating!
Or how about how when using an RPROMPT it makes copy/pasting stuff out of the terminal infuriate your IM buddies?
:)
Actually these are downsides, let's try fish instead, maybe?
% brew install fish
% fish
zsh: correct 'fish' to 'vis' [nyae]? GRRR
Shared history in zsh is essential to my workflow. I also keep many terminals open, and while I do separate them by task, I often just pick one which happens to be in the right directory and start typing away. I always search through history using Ctrl-R, and almost never use up-arrow cycling. Shared history makes this work seamlessly.
This is obviously configurable, so if you prefer a different workflow, zsh will accomodate it.
about the 3'rd thing, that's not a bash thing - that's a ubuntu thing, which nicely integrates with bash by default.
You could get the same thing by putting
function command_not_found_handler() {
/usr/bin/python /usr/lib/command-not-found -- $1
}
Zsh use's zle(Z-Shell Line Editor), which is different then libreadline as its part of the shell not a separate library. Zle's behavior is editable through your .zshrc.
Maybe I dumbed the post down too much, was just listing a few features that I use every day that IMO work better then the comparable Bash features.
Shared history can be either a burden or a godsend, I like it but I usually just end up using whatever basic bash shell I'm on without a custom config as most of the things I do are remote.
The zsh autocorrect works much differently than what you have given. You have shown a feature of ubuntu (and probably debian) that looks for packages matching/close to your given command but what zsh does is give you, depending on your chosen settings, full autocorrect.
Where you may be able to type gut status and get No command found the setup in zsh would allow either for gut status to be autocorrected to git status or would ask you if you meant git status while waiting for a confirmation.
Zsh has knobs for shared history. You can configure all terminals to have the same history at the same time, but I have it set to add history to the .zsh_history file immediately, but each shell gets it's own history. So ctrl-r in a shell lists commands entered into that shell (or preexisting when it started), and opening a new terminal starts with the shared history from all terminals. This is really the best of both worlds. Also there's a knob to only add a command if it isn't in the history, so no scrolling back over a dozen "cd .." or whatever.
Zsh has floating point math, for instance $((1.0/2)) is 0.5 instead of an error. This comes in handy sometimes in simple scripts.
Zsh is significantly faster.
Zsh autocomplete is much more advanced. Bash may have copied the pid completion and some other easy ones, but zsh has all sorts of completion hooks, for instance "svn help ch<tab>" expands to "changelist". It also runs --help and parses out GNU style help text for completing options.
Zsh completion also has optional Windows-style cycle mode, so you can do "prefix<tab><tab>"... and cycle through the matches instead of prefix<tab>a<tab><tab>b<tab>-<tab>" like in bash. I think you can actually make bash do this but it's some obscure key binding.
...basically zsh is just a bit better at everything.
im pretty sure bash does shared history if you desire it, the configuration is just not as directly obvious.
I prefer a long histfile (unlimited really, i. think i have it set to a million lines, but im at about 70 000. i even keep it backed up regularly because its fairly easy to trash the histfile if you are opening subshells and do the wrongthing. timestamped, too, which i find really handy.
that said, i do use and like zsh on my primary workstation, love it.. but i dont bother priming every other remote box with it, my bash config is simple and tweaked up just rightfor remote servers, and bash is there by default (dealing with older systems, etc.....i know zsh is installed by default often too)
# Append to ~/.bash_history instead of overwriting it -- this stops terminals
# from overwriting one another's histories.
shopt -s histappend
# Only load the last 1000 lines from your ~/.bash_history -- if you need an
# older entry, just grep that file.
HISTSIZE=1000
# Don't truncate ~/.bash_history -- keep all your history, ever.
unset HISTFILESIZE
# Add a timestamp to each history entry.
HISTTIMEFORMAT="%Y/%m/%d %H:%M:%S "
# Don't remember trivial 1- and 2-letter commands.
HISTIGNORE=?:??
# What it says.
HISTCONTROL=ignoredups
# Save each history entry immediately (protects against terminal crashes/
# disconnections, and interleaves commands from multiple terminals in correct
# chronological order).
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
Sorry for being off-topic, but do you know how the ZSH history file gets trashed? It's happened so often to me that I wrote a script to reconstruct my history file by combining the last handful of backups. I still haven't figured out how the history file gets trashed though :-(
guessing, but could you be invoking zsh in such a way occasionally that it is not reading your .zshrc? sudo or su come to mind..... this is what got me in bash a few times - exiting a shell that had just the wrong ssettings so it ioverwrote my history.
I like a long history too. I actually automatically rotate my history file every quarter (copying over the 500 most recent entries) and keep around my old history files. It's actually come in really handy when I want to do something I last did two years ago.
wow - would you know the settings for the whole shared history thing you wrote about. I have mine set up in a less than ideal way and have never been able to google for these settings.
These are the history setopt's I have, but I don't know if they all make sense with each other though. I set it up once and haven't touched it in years.
HIST_IGNORE_DUPS # don't add multiple 'cd ..', etc in a row?
HIST_EXPIRE_DUPS_FIRST # save unique hist entries longer
HIST_VERIFY # edit recalled history before running
INC_APPEND_HISTORY # add commands to .history immediately
EXTENDED_HISTORY # save timestamp on history entries
# set a huge history... doesn't seem to affect performance at all
HISTFILE=~/.zsh_history
HISTSIZE=10000
SAVEHIST=$((HISTSIZE/2))
For the completion I setopt AUTO_REMOVE_SLASH GLOB_COMPLETE MENU_COMPLETE NO_AUTO_LIST NO_BAD_PATTERN NO_BEEP NO_LIST_AMBIGUOUS NO_LIST_BEEP NO_NOMATCH, but I'm not sure what they all do ;-P
I like zsh. Probably my favorite feature is that it will autocomplete paths/filenames in an scp command on the remote end if authentication is done with keys.
Funnily enough, I find that the autocorrection tends to get in my way more often than not. Being prompted if I meant 'git' when I type 'gut' interrups my thinking flow, while 'command not found' doesn't. And the autocorrect is very bad for cp/mv ('mv test test1' will likely ask me if I meant 'test' instead of 'test1').
That being said, I'm a happy zsh user, for all it provides. Autocorrection is just one of the only things that, in my opinion, don't work well, so it's strange to market them.
alias cp='nocorrect cp' # don't correct spelling for 'cp'
alias mkdir='nocorrect mkdir' # don't correct spelling for 'mkdir'
alias mv='nocorrect mv' # don't correct spelling for 'mv'
Is anybody else addicted to shell mode within emacs?
I love having the shell as just another buffer right in the editor. Easy history searchability, copy and paste between code and various repls or SQL prompts, and all the other full editor features available at the prompt.
I like the idea, but I'm too used to bash's autocompletion (the Emacs-provided autocompletion is similar but not quite the same), the autocd option, CDPATH, etc. And changing directories in the shell with anything other than cd (pushd, or an alias or script) confuses Emacs's directory completion.
The last couple of days I've been trying terminal-mode rather than shell-mode, and it works much better. Many standard Emacs keybindings get remapped though.
Edit: I meant term-mode (M-x term), not terminal-mode (M-x terminal-emulator). No idea why there are two different terminal emulators in Emacs, but 'M-x term' seems the better of the two, or at least the keybindings make more sense to me.
There is also 'M-x serial-term' should you ever need it.
I used to use oh-my-zsh but gave up on it after a few months because it took almost 20 seconds to open up a Terminal tab. I switched back to bash with some really basic git completion and was happy enough, enjoying < 2 second opening times.
my tabs open up immediately but it does take a little while to log in, which really is annoying. I think depending on how you configure things you can move where and how often the wait occurs and by disabling certain things, how long it is.
+1 for actually giving me a couple reasons to try zsh. Of course I'd be surprised if many of these features aren't already hacked into some bash guru's dotfiles but, that said, more autocompletions without writing them myself is always nice.
Not really, you're not seeing bash have many more features because its simpler on the inside at the cost of sometimes breaking. Rather, it seems an example of " the most dangerous enemy of a better solution is an existing codebase that is just good enough"
Not sure that is the real reason. Zsh was not free software in the Linux formative years. It lost its chance, and mindshare, like so much commercial Unix
Zsh was never part of a commercial Unix, so I suspect you are thinking of Ksh. As far as I can tell, Zsh has always been free software: the earliest version I could find used the GPL, but it now uses something more MIT-like.
Bash is probably more widely used because it was available earlier than Zsh, and because it was the "official" shell of the GNU project (better marketing).
I used to use a lot of zsh at work, and one thing that drove me nuts was overzealous wildcard expansion.
>scp server2:~/folder/* .
zsh: no matches found: server2:~/folder/*
nothing in current work dir matches 'server2:~/folder/ * ', so zsh helpfully yells at me. yeah I know use single quotes to avoid expansion, and backslash should work too. It makes total sense because * is a reserved character, but still, bash got it. surely Zsh could've too ?
It probably got fixed since then, but this raw frustration is my most vivid memory from zsh usage.
This behavior can be turned off by adding this to .zshrc:
setopt no_nomatch # if there are no matches for globs, leave them alone and execute the command
zsh also tries to autocomplete directory names using variables in global namespace that point to directories. I found that behavior maddening and can be turned off with:
setopt no_cdable_vars # don't use named directories in cd autocompletion
Edit: I have setopt correctcall and I do not get this behaviour.
On an unrelated not, this is a classic example of complaining about why a product doesn't work and having users jump at the chance to fix your issue to prove it's worth.
Not sure what is lost with "unsetopt correct_all", but it fixes this annoyance.
"run-help" doesn't seem to do the trick. As an example, in Bash, "help for" will describe the for loop construct. "run-help" seems to just be an alias for "man" and on my system calls up the Tcl for man page.
Thanks mgrouchy for another site that breaks pgdn. The header that never moves hides some lines on the next page. Reading becomes an annoying series of page downs then scroll up a bit to read the hidden sentences. Does this annoy anyone else?
Hey, thanks for the feedback, I just recently changed the look of the blog after about a year of neglect. Its actually just Twitter Bootstrap(1.4). I never use page down or up so I completely missed the problem. I will see if I can find a workaround. Thanks again!
I tried that and about a million other things in Ubuntu. When I hit tab I see options, but nothing I put in my .zshrc will allow me to use the arrow keys or anything else to navigate the completion list.
I am using oh my zsh but I tried turning it off and it didn't seem to matter.
Due to the poor spelling and grammar, gross oversimplification of zsh's advantages, and the inclusion of oh-my-zsh as a reason to switch, I found this post insulting (as a long time zsh user). And I actually want more people to use zsh, because that would mean more collaboration, more tips, and better script compatibility.
If my grammer is shitty, thats fine, never said my grammar/spelling/etc was amazing, just Zsh.
This post was intended as a nice introductory shoutout to Zsh. Oh-my-zsh is a great way for someone to get started with zsh if they wanted to try it out. It was never meant to be a complete guide to Zsh, and I wasn't going to list all the features, just a few that people who don't know anything about Zsh might be interested in.
But Hey, thanks for trying to give me a hard time. Stay classy.
Due to the major douchebaggery, gross misunderstanding of the purpose of this article, and inclusion of your "long time user" status, I can't take you comment seriously. Perhaps the purpose of this article is too complicated for your oversimplified brain. As a "long time" computer user I appreciate Mr. Grouchy taking the time to outline some of the finer things zsh has to offer.
If you REALLY wanted people to adopt zsh, and grow the community, you should probably try to list some other things that you enjoy.
But Hey, thanks for trying to integrate yourself. Stay Classy.
I suppose having and stating an opinion that isn't kissing someone's ass makes me a douchebag according to richardlblair. I think I can live with that.
All Mr. Grouchy did was give a couple examples of completion and oh-my-zsh. I think you would have to be really fed up with bash or whatever default shell your system has to take that bait. I never said I expected him to write a complete job. I just think there are better arguments to be made.
In fact, there are hundreds of posts on HN that give someone's evangelical tale of trying a new program, and several about zsh. This one is far from exceptional in my mind.
To me, it was like saying "You should buy a Tesla Model S because they are really fast."
