| |
 |
|
|
|
|
 |
|
What are the differences among various shells?
|
|
A brief History of Unix Shells
|
| |
If you wish to be happy for one hour, get drunk.
If you wish to be happy for three days, get married.
If you wish to be happy for a month, kill your pig and eat it.
If you wish to be happy forever, learn to fish.
- Chinese Proverb
-
The Unix shell is most people's main access to the Unix operating
system and as such any improvement to it can result in considerably
more effective use of the system, and may even allow you to do things
you couldn't do before. The primary improvement most of the new
generation shells give you is increased speed. They require fewer key
strokes to get the same results due to their completion features, they
give you more information.
In the near beginning there was the Bourne shell
(/bin/sh) written by S. R. Bourne.
It had (and still does) a very
strong powerful syntactical language built into it, with all the features
that are commonly considered to produce structured programs; it has
particularly strong provisions for controlling input and output and in
its shell expression matching functionalities.
But no matter how strong its input
language is, it had one major drawback; it made nearly no concessions
to the interactive user (the only real concession being the use of
shell functions and these were only added later) and so there was a
gap for something better.
Along came the people from UCB (University of California, Berkeley)
and the C shell
(/bin/csh) was born. Into
this shell they put several concepts which were new, (the majority of
these being job control and aliasing) and managed to produce a shell
that was much better for interactive use. But as well as improving the
shell for interactive use they also threw out the baby with the bath
water and went for a different input language.
The theory behind the change was fairly good, the new input language
was to resemble C, the language in which Unix itself was written, but
they made a complete mess of implementing it. Out went the good
control of input and output and in came the bugs. The new shell was
simply too buggy to produce robust shell scripts and so everybody
stayed with the Bourne shell for that, but it was considerably better
for interactive use so changed to the C shell, this resulted in the
stupid situation where people use a different shell for interactive
work than for non-interactive, a situation which a large number of
people still find themselves in today.
After csh was let loose on an unsuspecting world various people
decided that the bugs really should get fixed, and while they where at
it they might as well add some extra features. In came command line
editing and several other features - Tc shell
(/usr/local/bin/tcsh). Out went most of
the bugs, but did the various Unix operating system manufacturers
start shipping tcsh instead of csh? No, most of them stuck with
the standard C Shell, adding non-standard features as they went along.
Eventually David Korn from AT&T had the bright idea to sort out this
mess and the Korn shell
(/bin/ksh) made
its appearance. This quite sensibly junked the C shells language
and reverted back to the bourne shell language, but it also added
in the many features that made the C shell good for interactive work
(you could say it was the best of both worlds), on top of this, it
also added a some features from others. The Korn shell became part
of System V but had one major problem; unlike the rest of the Unix
shells it wasn't free, you had to pay AT&T for it.
It was at about this time that the first attempts to standardize Unix
started in the form of the POSIX [Portable Operating System - Unix]
standard. POSIX specified more or less the System V Bourne Shell
[by this time the BSD (Berkeley Software Distribution) and System V
versions had got slightly different]. Later the standard is upgraded,
and somehow the new standard managed to look very much like ksh.
Also at about this time the GNU project was underway and they decided
that they needed a free shell, they also decided that they wanted to
make this new shell POSIX compatible, thus the Bourne again shell (/usr/local/bin/bash) was born. Like the Korn shell, bash was
based upon the Bourne shells language and like the Korn shell, it also
pinched features from the C shell and other operating systems (in my
opinion it put them together better; guess which shell I use), but
unlike the Korn shell it is free. Bash was quickly adopted for Linux
(where it can be configured to perform just like the Bourne shell), and
is the most popular of the free new generation shells. Bash was
originally written by Brian Fox of the Free Software Foundation. The
current developer and maintainer is Chet Ramey of Case Western Reserve
University.
Meanwhile Tom Duff faced with the problem of porting the Bourne shell
to Plan 9, revolts and writes
rc instead,
he publishes a paper on it, and Byron Rakitzis reimplements it under
Unix. With the benefit of a clean start Rc ended up smalled, simpler,
more regular and in most peoples opinion a much cleaner shell.
The search for the perfect shell still goes on and the latest entry
into this arena is Z shell
(/usr/local/bin/zsh).
Zsh was written by Paul Falstad while he was a student a Princeton
and suffers from slight case of feeping creaturism. It is based
roughly on the bourne shell (although there are some minor but
important differences) and has so many additional features that
I don't even think the author even knows all of them.
Additionally rc has been enhanced to produced es,
this shell adds the ability for the user to redefine low level kernel functions.
|
|
A Checklist before Deciding on Your Shell
|
| |
-
Which of the many shells you choose depends on many different things,
here is what I consider to be the most important, you may think
differently.
|
How much time do I have to learn a new shell?
|
- There is no point in using a shell with a different syntax, or
a completly different alias system if you havn't the time to
learn it. If you have the time and are presently using csh or
tcsh, it is worth considering a switch to a Bourne shell
variant (i.e., bash or zsh).
-
|
What do I wish to be able to do with my new shell?
|
- The main reason for switching shells is to gain extra
functionality; its vital you know what you are gaining from the
switch.
-
|
Do I be able to switch back to a different shell?
|
- If you have to switch back and forth to a current/standard shell, it is
quite important you don't become too dependent on extra
features only available on the new shell you switched. In other word,
switching shell should make your life easier, not more difficult.
-
|
How much extra load can the system cope with?
|
- The more advanced shells tend to take up extra CPU, since they
work in cbreak mode; if you are on an overloaded machine they
should probably be avoided; this can also cause problems with
an overloaded network. However, this only really applies to very old
systems nowadays. (Go ahead and knock yourself out with experimenting
with different shells. CEE UCL can handle all of them quite nicely.
 )
-
|
What support is given for my new shell?
|
- If your new shell is not supported by
OCCS USG, make sure you have someone
you can ask if you encounter problems or that you have the time
to sort them out yourself.
-
|
What shell am I using already?
|
- Switching between certain shells of the same syntax is alot
easier than switching between shells of a different syntax. So
if you havn't much time a simple upgrade (eg csh to tcsh) may
be a good idea.
-
|
Can I afford any minor bugs?
|
- Like most software all shells have some bugs in them
(especially csh), can you afford the problems that may occur
because of them.
-
|
Do you need to be able to use more than one shell?
|
- If you use more than one machine you may discover that you need
to use more than one shell regularly. How different are these
shells and can you cope with having to switch between these
shells on a regular basis? It may be to your advantage to
choose shells that are similar to each other.
|
|
Comparison of Different Shell Features
|
| |
-
Table below lists most features that you can use to choose one shell
over another. It is not intended to be a definitive list and does not
include every single possible feature for every single possible shell.
A feature is only considered to be in a shell if in the version that
comes with the operating system, or if it is available as compiled
directly from the standard distribution.
| Y |
Yes |
Feature can be done using this shell |
| N |
No |
Feature is not present in the shell |
| F |
Function |
Feature can only be done by using the shells function mechanism |
| L |
Library |
The readline library must be linked into the shell to enable this Feature |
|
| |
Feature |
|
sh |
csh |
ksh |
bash |
tcsh |
zsh |
rc |
es |
|
| |
Job control |
|
N |
Y |
Y |
Y |
Y |
Y |
N |
N |
|
| |
Aliases |
|
N |
Y |
Y |
Y |
Y |
Y |
N |
N |
|
| |
Shell functions |
|
Y(1) |
N |
Y |
Y |
N |
Y |
Y |
Y |
|
| |
"Sensible"
Input/Output redirection |
|
Y |
N |
Y |
Y |
N |
Y |
Y |
Y |
|
| |
Directory stack |
|
N |
Y |
Y |
Y |
Y |
Y |
F |
F |
|
| |
Command history |
|
N |
Y |
Y |
Y |
Y |
Y |
L |
L |
|
| |
Command line editing |
|
N |
N |
Y |
Y |
Y |
Y |
L |
L |
|
| |
Vi Command line editing |
|
N |
N |
Y |
Y |
Y(3) |
Y |
L |
L |
|
| |
Emacs Command line editing |
|
N |
N |
Y |
Y |
Y |
Y |
L |
L |
|
| |
Rebindable Command
line editing |
|
N |
N |
N |
Y |
Y |
Y |
L |
L |
|
| |
User name look up |
|
N |
Y |
Y |
Y |
Y |
Y |
L |
L |
|
| |
Login/Logout watching |
|
N |
N |
N |
N |
Y |
Y |
F |
F |
|
| |
Filename completion |
|
N |
Y(1) |
Y |
Y |
Y |
Y |
L |
L |
|
| |
Username completion |
|
N |
Y(2) |
Y |
Y |
Y |
Y |
L |
L |
|
| |
Hostname completion |
|
N |
Y(2) |
Y |
Y |
Y |
Y |
L |
L |
|
| |
History completion |
|
N |
N |
N |
Y |
Y |
Y |
L |
L |
|
| |
Fully programmable
Completion |
|
N |
N |
N |
N |
Y |
Y |
N |
N |
|
| |
Mh Mailbox completion |
|
N |
N |
N |
N(4) |
N(6) |
N(6) |
N |
N |
|
| |
Co Processes |
|
N |
N |
Y |
N |
N |
Y |
N |
N |
|
| |
Builtin artithmetic evaluation |
|
N |
Y |
Y |
Y |
Y |
Y |
N |
N |
|
| |
Can follow symbolic
links invisibly |
|
N |
N |
Y |
Y |
Y |
Y |
N |
N |
|
| |
Periodic command execution |
|
N |
N |
N |
N |
Y |
Y |
N |
N |
|
| |
Custom Prompt (easily) |
|
N |
N |
Y |
Y |
Y |
Y |
Y |
Y |
|
| |
Sun Keyboard Hack |
|
N |
N |
N |
N |
N |
Y |
N |
N |
|
| |
Spelling Correction |
|
N |
N |
N |
N |
Y |
Y |
N |
N |
|
| |
Process Substitution |
|
N |
N |
N |
Y(2) |
N |
Y |
Y |
Y |
|
| |
Underlying Syntax
(shell category) |
|
sh |
csh |
sh |
sh |
csh |
sh |
rc |
rc |
|
| |
Freely Available |
|
N |
N |
N(5) |
Y |
Y |
Y |
Y |
Y |
|
| |
Checks Mailbox |
|
N |
Y |
Y |
Y |
Y |
Y |
F |
F |
|
| |
Tty Sanity Checking |
|
N |
N |
N |
N |
Y |
Y |
N |
N |
|
| |
Can cope with
large argument lists |
|
Y |
N |
Y |
Y |
Y |
Y |
Y |
Y |
|
| |
Has non-interactive
startup file |
|
N |
Y |
Y(7) |
Y(7) |
Y |
Y |
N |
N |
|
| |
Has non-login startup file |
|
N |
Y |
Y(7) |
Y |
Y |
Y |
N |
N |
|
| |
Can avoid user startup files |
|
N |
Y |
N |
Y |
N |
Y |
Y |
Y |
|
| |
Can specify startup file |
|
N |
N |
Y |
Y |
N |
N |
N |
N |
|
| |
Low level command
redefinition |
|
N |
N |
N |
N |
N |
N |
N |
Y |
|
| |
Has anonymous functions |
|
N |
N |
N |
N |
N |
N |
Y |
Y |
|
| |
List Variables |
|
N |
Y |
Y |
N |
Y |
Y |
Y |
Y |
|
| |
Full signal trap handling |
|
Y |
N |
Y |
Y |
N |
Y |
Y |
Y |
|
| |
File no clobber ability |
|
N |
Y |
Y |
Y |
Y |
Y |
N |
F |
|
| |
Local variables |
|
N |
N |
Y |
Y |
N |
Y |
Y |
Y |
|
| |
Lexically scoped variables |
|
N |
N |
N |
N |
N |
N |
N |
Y |
|
| |
Exceptions |
|
N |
N |
N |
N |
N |
N |
N |
Y |
|
| |
Feature |
|
sh |
csh |
ksh |
bash |
tcsh |
zsh |
rc |
es |
|
Notes to the table above;
| (1)
| This feature was not in the orginal version, but has since become
almost standard. |
| (2)
| This feature is fairly new and so is often not found on many
versions of the shell, it is gradually making its way into
standard distribution. |
| (3)
| The Vi emulation of this shell is thought by many to be
incomplete. |
| (4)
| This feature is not standard but unoffical patches exist to
perform this. |
| (5)
| A version called 'pdksh' is freely available, but does not have
the full functionality of the AT&T version. |
| (6)
| This can be done via the shells programmable completion mechanism. |
| (7)
| Only by specifing a file via the ENV environment variable. |
|
|
|
