Slashdot Mirror
Which Shell Do You Prefer?
Pascal de Bruijn asks: "I recently started to use NetBSD, the first thing I noticed was that it didn't have a command-line history. So I immediately wanted to switch my shell, being on BSD my first instinct was to change to tcsh, but many people told me it wasn't any good. Others recommended zsh. I would really like to hear your opinions about shells." The submitter is particularly interested in shell memory usage, and the features you like...and dislike...from the current options that are available, today.
did you try enabling it, it's off by default
set history=1000
- or maybe -
history = 1000
- or possibly -
set history 1000
I've never seen a shell without command line history, but I've logged into a lot of places where it wasn't turned on by default.
Chris Kuivenhoven is a thief, beware
It? Command-line history isn't a feature of an operating system, it's a feature of a shell.
Read csh programming considered harmful. It's not really sensible to write shell scripts using one shell and use another, so steer clear of csh.
Many people like zsh for it's completion routines, but I believe bash has similar facilities by now.
I originally chose this shell back in '92 for the right hand prompt. A 'spiff' feature for a shell chocked full of features. It was also the first shell to have a truly programmable completion. It has all the interactive add-on's for tcsh, with the base template built off of Korn Shell (so you don't have issues with scripting in something separate from a Bourne derivative).
The z-shell is so filled with features at this point, it's nearly become the "emacs" of shells, and yet, it's memory footprint for the same tasks is smaller than either bash or tcsh.
When picking a shell, you should consider:
The candidates:
sh is too primitive in terms of user features, period. No one uses the Bourne shell if they can help it.
csh/tcsh...well, google for "csh Programming Considered Harmful" to see its many internal bugs. Also, most of the major Unices don't use it (Solaris, AIX, Linux - I guess *BSD might still) for their system stuff. If it's not considered a good scripting platform AND most Unices don't use it for their scripts...
zsh - From what I've read, a good shell, but very nonstandard. Do you really want to lug a shell around and install it (and set up /etc/shells or whatever each time, etc.) for every machine you log into?
ksh - sh scripting with all the good interactive features. A really solid shell and a very good choice. All the sh goodness with the t/csh interactive features added.
bash - I think bash is a little better than ksh because some of its interactive features are better. Tab-completion is better than ESC-\. The way the shell handles tab completion is better (X possibilities, do you want to see?) Lots of little things like that. Benefits greatly from reimplementing ksh. Installed by default on all Linux distros (except tiny niche players) and Solaris since Solaris 8...easy to build and install on AIX or *BSD (and HP-UX I'd guess, I don't know)
bash is the best shell in my opinion and I have no qualms about defending it. ksh is a reasonable second choice and some people prefer it. zsh may be in the running but never caught on widely. Everything else is inferior.
Advice: on VPS providers
Some random facts:
The only real choices today as far as user login shells go are bash 2.x, ksh (ksh93, not ksh88), and zsh, all of which continue to cross-pollinate good ideas.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
i was convinced by adam spier's page and the zsh faq to give zsh a try - it was even a netbsd system that prompted it. i got sick of administering freebsd/opensbd/netbsd with different shells and i wanted to standardize on something with the features i wanted.
:) the basics are largely identical.
bash was tried first, but when i started playing with misc options like vi mode, got deeper into completion, etc i realized that bash/ksh weren't appropriate long-term choices for me. auto cd to directories, amazing completion options, typo correction, shared history, and a proper vi mode (see this for the confession from gnu's docs).
'knowing' zsh will largely translate to bash/ksh systems when you use them and zsh is not available - you'll just be reminded of their shortcomings
the new unix power tools book also makes much mention of zsh.
When I first used UNIX, it was ksh. I had gotten used to ESC-ESC for name completion. Then I got my NeXT and liked TAB for completion under csh. Much better. When I found out that bash had the same thing but TAB-TAB prints all possible matches, I was hooked from then on. Plus, much of the settings are the same as ksh and scripting is about the same.
I tried zsh but its man page is like Perl's, referencing a bunch of other man pages, making navigation/reference cumbersome. tcsh's configuration is different enough from [bk]sh's that I stopped using it in short order.
So it's bash for me. It's a good thing bash is available under OS X. Early versions had only sh, csh, and tcsh and things were painful. Recent versions have all those, including bash and zsh.
There certainly is a history in the default shell (/bin/csh) on NetBSD. Type the 'h' command to see your numbered command history. Then type, for instance !3 to repeat the third command on the list, or !! to repeat the most recent command.
But if we wanted to have a shell war, maybe I am just being pedantic and interfering.
I would vote for zsh, personally.
I've actually had bash segfault on me a few times, which zsh has never done. and zsh uses less memory unless you do abusive things via scripting or the command line editor. zsh scripting is a superset of sh, so the things I try generally work; csh users can have a similar experience after setting a few options. (But remember, csh programming Considered Harmful.) I've become accustomed to spiffy zsh features like reporting when other users log in and out (before the prompt, just like new mail), extended globbing, very customizable completion behavior, being able to tab-expand history references (makes trying "!rm" much less dangerous), and so forth.
It's even the little things. Like, zsh expands commands when it prints a job completion report, but bash doesn't; so if you have a loop which does something on a bunch of items, each of which can complete in the background, under bash you get a report where each item looks like "[%] Done wget $i" or something equally useless, but under zsh you can see the actual text of the command that finished.
I have 100+ lines invested in the four rc files for zsh by now, so something new might not be immediately superior for me. I have been meaning to seriously try out es and rc for years.
Java: the COBOL of the new millenium.
Of course I realise you're joking, but Emacs actually does come with a built-in shell, eshell.
What rocks about it is that it's written in Emacs lisp, so you can use it on anything Emacs runs on. It's very nice to be able to fire up a Unix-like shell on Windows for those of use who prefer a cli approach and have never adapted to the MS-DOS tradition.
Still though, when I am in a Unix environment I like zsh for my login shell, which still has a more features.
While surfing the web for FAQs on UNIX shells, I came across this popular FAQ on the differences between shells and how to choose.
There's a great table in there that lists the features of each.
Programmable completion has been in bash for a while now. See the original project page for more, or use the debian bash package, which includes the completion libraries by default.
I actually had to disable the cvs-subcommand-autocomplete. I would try to complete the name of an actual file, and the cvs-completion would fire... generating network traffic to the CVS server... taking forever... when all I wanted was a local filename.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
When I'm the root user, my shell is
Ever. Ever. EVER. Instead, in root's
All my scripting is done using
For simple sysadmin-type tasks, the bourne shell has almost all the features you need
--NBVB
If you want a small memory footprint, try the embeddable shell alternative: BusyBox.
"BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add /dev, /etc, and a kernel."