Debate and study the differences between Unix shells in this item.

35 responses total.

Bourne shell and its derivatives = good
C shell and its derivatives = evil

C shell is okay as long as you don't try to write scripts in it.

Would someone knowledgeable in the subject please post a quick (and
preferably untainted by overt bias) summary of the primary feature
differences between the top several command shells?  If possible, also
list generally recognized positive and negative features of each.

The Bourne Shell: /bin/sh (or direct replacement)

The standard 7th Edition shell.  Originally, quite a weird implementation
(it allocated memory by trapping signals and increasing the size of the data
segment instead of just calling malloc, and used preprocessor symbols to
make the code look like a sort of weird variant of ALGOL).  Most modern
versions contrain job control.

The C-Shell: /bin/csh

Developed at Berkeley by Bill Joy.  Descended from the 6th Edition shell
and, while it has some useful features (job control, command history and
associated syntax for its manipulation, file name completion, the use of the
tilde (~) to refer to a user's home directory [default current user]), it
lacks some of the better ones incorporated into the Bourne shell (like the
ability to redirect individual file descriptors.  E.g., for output, you can
either redirect stdout (>) or stdout and stderr together (>&).  In
particular, you cannot easily redirect stderr independently of stdout).  CSH
was designed to have a "C-like" syntax, but I've never really understood
this; it doesn't look particularly C-like to me.  At this stage, mostly
historical.

The Tenex C-Shell: tcsh (non-standard)

This took the C shell, and added to it "Tenex-style" command and filename
completion, and command line editting using vi or emacs style keybindings
(similar to GNU's readline library).  Much more usable than pure C shell
once you get the hang of it.

The Korn Shell: /bin/ksh

Developed at AT&T by David Korn and others.  Derived from the Bourne shell,
but with command recall facilities similar to CSH and many other advanced
features (a command-line editting facility with either emacs or vi modes,
etc).  Supposedly the basis for the POSIX shell, though most systems ship
some sort of Bourne-like shell or derivitive, or the C shell.

The Bourne-again Shell: bash (non-standard)

The GNU reimplementation of the Bourne shell, with lots of new features and
enhacements.  It features command and filename completion, command line
editing, job control, command history and recall with editting, etc.  Pretty
much standard on Linux, much more capable than the original Bourne shell,
and containing pretty much the union of features of all the shells
previously mentioned.  Often criticized for being *too* big and
correspondingly slow.

The 9th Edition Shell: rc (non-standard)

A brand new shell with a syntax reminiscent of the Bourne shell, but far
more regular.  This one actually looks kinda like C; it's far simpler than
any of the others listed here,  but remains powerfl.  It has been adopted as
the standard shell under Plan 9.  Cedes things like job control, history,
command history and command line editing to other programs (under Plan 9,
the window system mostly).

The Extensible shell: es (non-standard)

Based on a Unix-only clone of rc, featuring an embedded Scheme interpreter.
Interesting, but not hugely popular.  A patch to add job control exists.

The Z shell: zsh (non-standard)

Another Bourne-derived shell, quite full-featured.  Nate and Jeff are both
users of zsh; perhaps they can comment further.

I think that's most of the biggies.

Some of the BSDs (and probably some of the Linux distributions) also used
cut-down or statically-linked shells such as ash, either for system repair
or as the default shell for root (the administrator account). 

ZSH has some nifty features, such as being able to go to a directory by typing
its name alone, instead of after "cd", and completion for just about
everything (such as command options and manpages). For example, if I have the
following files in my home directory:

README_Solaris8.txt
README_Solaris9.txt
REALLY_LONG_FILE.txt

and want to read README_SOlaris9.txt. If I type:

cat R<tab><tab>

The shell will beep on the first <tab> and display a list of files beginning
with R. If I then type the letters the two README files have in common,
("EAD") and then <tab> the shell will type out:

$ cat README_Solaris

If I then type 9<tab>, the shell will then complete README_Solaris9.txt.

It's even more useful when trying to find a manpage!

One feature I remember seeing somewhere, but now can't remember where, 
is a directory stack.  You could 'push' on the current directory, 
change to another one, do some work, then 'pop' back to the original 
one.  It's a feature I've occasionally wished for when I was deep in a 
directory hierarchy.

tcsh has that feature; I suspect bash and a few of the others do as well. 
Wow, I've forgotten a lot.  I do remember that csh does the same.

there's also tclsh .

Probably not what you'd want to use for interactive use....

Re #6:  pushd and popd are in csh, tcsh, and zsh (but not sh or ksh).

John, did you check bash at all?

Looks like bash has it, too.  What's weird is I thought I'd looked for 
it and failed to find it.  I think I was probably looking at the 
bash(1) manpage instead of the bashbuiltins(1) one.

That's another complaint about bash: too many man pages and startup files.
Well, that's my complaint, anyway.

zsh, simple yet powerful. I've been using it ever since my slackware days.

Re resp:13: I'd agree with that criticism.  I suppose the classic 
GNUish answer would be to use the info pages, instead, but I've never 
liked info.

No, neither have I.

Re #11: Oops, yes, checked bash but forgot to list it.

Party of the problem with info pages is that they force a specific usage
model.  It works fine if you "live" within emacs and are used to that style,
but kind of sucks if you want to, say, pipe info through other things, etc.

re 9 srsly

I have been using bash for several years.  Before that I was a tcsh user
for several years because it was better than csh (a few years) by a lot,
and those two supported command aliasing while bash did not at that
time.  Once Bash got command aliasing (and I actually noticed it) I got
tired of making sure my environment had tcsh.

How do I detect that the previous command has been suspended?
csh has $status set to 1 on such occasions.  This is the same as when the
command returned EXIT_FAILURE.

Sh and bash use $? for exit status.

So they do; it does not affect my question: how do I detect that the previous
command has been suspended?  I would expect some high bit set in the return
code in order to distinguish it from a regular exit.

I don't know the answer, and a little Google searching (which I imagine
you've tried too) didn't turn one up for me.  But since a suspended
command hasn't really "exited", I'm not sure I'd expect suspension to be
reflected in the value of an "exit status" variable anyway.

Does someone else know?

On a somewhat related matter, my searching did turn up a difference
between bash and tcsh in the semantics of the "&&" operator.  If you do

    echo one && sleep 20 && echo two

in bash, and then suspend the sleep with ctrl-z, "$?" is set to 0 and
"echo two" is executed immediately, even though the sleep hasn't exited.
 But if you execute the same sequence in tcsh and suspend with ctrl-z,
"$?" is set to 1 and "echo two" is *not* executed.

Hmmm...  I wonder what the correct POSIX behavior is.

Neither do I --- but it would be obvious for POSIX to follow Bourne.

After tiring of the Grex menush, I decided to give tcsh a try for historic
interest (bash is my standard shell on Un*x systems where I have a choice).

I installed the tcshrc Project (https://sourceforge.net/projects/tcshrc/)
initialization files to give myself a head start. I found that the Project
assumes you're using a variety of Linux, so it took a little hacking to get
some of the features working on Grex's OpenBSD, which was both annoying and
fun.

I will not bother with tsch scripts beyond dabbling with the initialization
files. Within that range, although the syntax is different from the more
familiar Bourne-like shells, I have encountered no problems.

Overall, I like tcsh fine, with very little difference from bash for ordinary
use. I have not been able to get the incoming mail watch feature to work,
though I don't get much mail on Grex. tsch has a login watcher that I think
bash lacks which is interesting.

I guess that either tcsh or csh is or was the default shell on Grex because
the system-wide cshrc file looks like it's had quite a bit of customization.

tcsh is my preferred shell and has been for a long time.  

Why do you prefer tcsh over something like bash? They seem
very similar to me.

While they are similar, I like the vi command line in tcsh
much better than than in bash. I like all the features in
tcsh better. I don't do shell scripts in tcsh though.

I prefer Emacs key bindings for command line editingand
haven't noticed any problems with tcsh there.

I occasionally miss bash command syntax and redirection
options for longer complex commands. But it doesn't come
up often on Grex.

Long live bash and vi (though cash shell would make me happier)

I've been using tcsh (with the tcshrc package
https://sourceforge.net/projects/tcshrc/) since I came to Grex. It's not
bad, but the small differences with bash are becoming more annoying. I'm
thinking of switching back to bash.

tcsh can't find executables in the directory at the end of my $path list. Have
I missed some setting that will fix that?

I can't recreate the $path problem now. Never mind.

I used tcsh for nearly 20 years but switched away about a decade ago. Everyone
around me used bash, so I felt I should adapt instead of expecting the world
to accommodate me. Then I started using zsh most places.

Oh, PS: If you added or moved a command and experience that problem again,
try running `rehash`.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss