QQ11@LIVERPOOL.AC.UK (11/09/90)
[ this summary was produced by a colleague on whose behalf I posted the
original question. Please do not mail/post if the summary does not
fit in with your view of which shell is best. The summary is based on
the mail received.
Many thanks to all who replied ]
Here's a summary of the comments made in response to the question
"I would be interested to hear from any organisation, especially one
with a research/teaching environment, who has decided on a particular
shell and why.
I'm interested in how you made your decision, whether more
consideration went into interactive use than programming use, whether
the choice was correct with hindsight and if you didn't use
sh/csh/ksh, which one did you select and why?"
Of the replies received (so far 26) the shells recommended and in use
were:
Recommended In Use
Interactive Programming Interactive Programming
ksh 10 8 8 7
bash 6 4 1 1
csh 2 7 2
sh 1 5 2 5
clyde 1 1
tcsh 1 1 2 1
msh 1 1
perl 1
BRL's sh (R2) 1 1
BRL's sh (R3) 1 1
expect 1
Listed below is a summary of the comments made about each shell. They
are the views expressed by the respondents, not necessarily the views
of the Liverpool University Computer Laboratory.
1. Bourne Shell
o is the standard UNIX shell.
o comes with every UNIX system.
o used for programming. Compatible with all shells.
o fully parses the control structure.
o is very reliable.
o doesn't have either history recall or background job
capabilities.
o not suitable for an interactive shell, not having any history
mechanism or job control.
o with windowing sh is the most appropriate, because it's small
and fast therefore there isn't a large cost in starting up a
new window. Other shell have features which are not required
when using shells under a windowed environment.
o University of Bath (UK) currently gives the users sh by default.
o shows its age
2. Korn Shell
o is basically a superset of sh, so sh users can easily migrate
to ksh.
o largest gain over sh and csh is automatic command and filename
completion. Its control structures are also supposed to be
augmented, and it pays attention to a more diverse set of
user-settable environment-configuration variables.
o much better than csh from several major standpoints:
- has history editing - this is a big plus
- changes to keep up with things like POSIX standards for
shells, new features of the OS, etc. Csh is stagnant.
- ksh versions are available for lots of machines, even if
you don't have a source licence (if your machine doesn't
have a csh binary, you have to have an AT&T source licence
to get it, whereas, ksh source can be bought from the AT&T
toolchest for $3,000).
- a ksh work-alike is available in source absolutely free
from GNU.
- csh users generally have to learn sh syntax anyway to
write efficient shell scripts and to read other people's
scripts.
o programming is upward-compatible with /bin/sh.
o the interactive features were MUCH nicer than csh's. Alias
and ~user have been stolen from csh, and the history editing
is a friendly screen-editor-like approach using vi or emacs,
and you also had a command-based history "r" or "r foo".
o No question about it, ksh is by far the superior shell.. Here
at work, most people seem to like csh, since they come from an
academic environment, but they are slowly being converted to
ksh when they see the ease of recalling and editing old
commands.. Plus, there is the added advantage of it being
compatible with the standard Bourne shell.
o ksh is probably the fastest of all of the shells. It has the
good sh syntax and many of the good tcsh features. It has
some features that are not in any of the other shells also.
Since it is upward compatible with sh, which is mostly
standard, there is no problem making it portable, since you
only pay for the features that you use.
o isn't available everywhere.
3. C-Shell
o comes with every unix system.
o is used by maybe 80% of the unix community.
o is better for command-line input, since it provides a history
mechanism, and has a simpler (if less logical)
control-structure syntax, which improves ease of command
entry.
o is better than sh (history, alias etc.) in interactive use.
o for interactive use, history was nice to have, but csh's
version is awkward to use.
o is too awkward to program (compared to sh), and you have to
make sure that any programs you write will really get executed
by csh (the #!csh feature is HIGHLY non-portable, and the
conventions for using csh vs sh based on initial comment
characters is also bogus.)
o The job control features which people often associate with csh
are really operating-system based; csh has hooks for them and
sh doesn't. Ksh does, so you can still use them.
o There are a number of bugs in csh, and a number of very bad
design choices, which make it unsuitable for programming.
o For programming most people recommend sh over csh
o If you plan to do any serious shell programming, you will come
to loathe "csh" due to a questionable decision made early on:
it does not fully parse its control structures, which means
that things like nested "if" statements don't work right.
o University of Warwick (UK) give everybody /bin/csh by default, but
make it plain that if they want it changed, it will be.
o shows its age.
4. Bash
o Bash is basically a reimplementation of ksh (with some other
stuff thrown in as well).
o Its command syntax if the same as the Bourne shell. If
anything at all is is a super-Bourne shell.
o bash is usually obtained from public-domain-software sources.
It offers, as its largest gain over sh and csh, automatic
command and filename completion. Its control structures are
also supposed to be augmented, and it pays attention to a more
diverse set of user-settable environment-configuration
variables.
o used mostly by people who want the few additions and don't
have ksh.
o has effective interactive functionality, and sh scripts are
upward compatible to it.
o combines the good things in csh (like ~/ instead of $HOME/,
good job control, etc) while allowing you to do programming
stuff with the power of sh.
o has almost book-length buglists.
o I have heard that bash is buggy, but haven't noticed.
o Bash keystrokes are exactly the same as emacs. So, using
emacs and bash, you have only ONE set of keystrokes in your
head.
o in the absence of 'ksh' use 'bash' or 'csh' in that order.
o With the next release of GNU's bash it may come out ahead of
ksh, right now there are just too many little problems running
it under SysV.
o When Bash 1.06 comes out, University of Bath plan to offer
that as the standard shell.
o When the GNU shell, bash, stabilizes a bit more, this will be
worth a good look. It is Bourne/Korn shell compatible, and
has lots of nice features. I currently have it up, and will
set people's shell to it if they ask me, but I really do not
consider it solid enough to use as a login shell, and don't
advertise it. I expect the next release to be a lot better, and
I would guess that will be available about Christmas time.
o if you don't have ksh (or can't afford it) I recommend bash
from GNU, which has most of the same features, but seems to be
slower.
o In the process of considering we just had to make sure it was
portable to all of our platforms, and it was (with a little
effort, though). So, it can be ported to: Apollo
(3000+4000+10000), HP (300+400+800), Tektronix (88000), Sun
(Sp1).
5. Tcsh
o is usually obtained from public-domain-software sources...
o used mostly by people who want the few additions and don't
have ksh.
o a hacked up version of csh with command line editing.
o I don't give this as standard because
a. it isn't standard, so if people get used to it here
they'll be confused when they go elsewhere
b. tcsh uses the emacs editing set whereas our most used
editor doesn't (although this is changing).
o We use tcsh at the moment, it is a modified csh which supports
command line editing and retrieval in a similar manner to VMS.
We view this as a temporary measure until V.4 arrives with
ksh. I understand the ksh also supports these features.
o Definitely and without question, you should go for tcsh
(pronounced tee-shell). This is an extension of csh, i.e.
all csh syntax works for it, but additionally it has a bunch
of features that are extremely useful and friendly.
Most important is the command line editing mechanism - if you
make a typo in a command line which generates an error, you
can type "up-arrow" and it brings back the erroneous command
line, at which point you can edit that line interactively
(using emacs syntax commands) and hit [RETURN] to execute the
corrected command. This can save you a LOT of typing,
especially for long and intricate commands
o Another very useful function in tcsh is command line
completion.
6. expect
o is a shell intended primarily to control interactive programs.
Using expect, you can program things that can only be done
interactively with other shells. For example, running telnet,
passwd, su, tip, etc, doing job control, etc.
7. BRL's sh
o This includes interactive support features the equal of or
superior to those in other known shells (including tcsh),
while avoiding the design mistakes of shells like "csh" and
"ksh". At some time in the future I'll be upgrading our shell
to SVR3.2 or SVR4 compatibility; meanwhile the SVR2 version is
heavily used here.
8. Perl
o perl which combines features from sh, C, awk and sed. I means
that you don't have to get into awk and sed as soon as you
want to do any text manipulation. Its written by Larry Wall
(who wrote patch) and has its own news group
9. msh
o is also a Bourne shell derivative, with screen based editing,
job control etc. Most people at the University of Bath (UK)
use either 'sh', cos thats what they get given, or msh.
--
Alan Thew
University of Liverpool Computer Laboratory
Bitnet/Earn: QQ11@LIVERPOOL.AC.UK or QQ11%UK.AC.LIVERPOOL @ UKACRL
UUCP : ....!mcsun!ukc!liv!qq11 Voice: +44 51 794 3735
Internet : QQ11@LIVERPOOL.AC.UK or QQ11%LIVERPOOL.AC.UK @ NSFNET-RELAY.AC.UK