home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
answers
/
unix-faq
/
shell
/
shell-differences
< prev
next >
Wrap
Internet Message Format
|
1993-12-10
|
13KB
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!usc!howland.reston.ans.net!EU.net!uknet!ukc!gos.ukc.ac.uk!bnb
From: bnb@ukc.ac.uk (B.N.Blackmore)
Newsgroups: comp.unix.shell,comp.unix.questions,news.answers,comp.answers
Subject: UNIX Shell differences and how to change your shell (Monthly Posting)
Followup-To: comp.unix.shell
Date: Fri, 10 Dec 93 14:40:54 GMT
Organization: Univeristy of Kent at Canterbury, England, UK
Lines: 207
Sender: bnb@ukc.ac.uk
Approved: news-answers-request@MIT.Edu
Expires: 21 Jan 1994 14:40:53 GMT
Message-ID: <7598@gos.ukc.ac.uk>
NNTP-Posting-Host: gos.ukc.ac.uk
Xref: senator-bedfellow.mit.edu comp.unix.shell:14035 comp.unix.questions:65940 news.answers:15641 comp.answers:2936
Archive-name: unix-faq/shell/shell-differences
Version: 1.0
The following article answers the frequently asked questions, what
UNIX shells are available, what are the differences between them and
how do you change your interactive shell.
WHY CHANGE YOUR SHELL
The UNIX shell is most peoples 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 alot less key strokes to
get the same results due to their completion features, they give you more
information eg. showing your directory in your prompt, showing which files
it would complete to, and they cover some of the more innoying features of
UNIX, such as not going back up symbolic links to directories.
A BRIEF HISTORY OF UNIX SHELLS
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 is particularly strong
provisions for controlling input and output and in its expression matching
facilities. 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 where only
added later) and so there was a gap for something better.
Along came the people from UCB and the C-Shell /bin/csh was born. Into
this shell they put several concepts which where new, (the major 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.
Eventually somebody 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 load of features from other operating
systems (the primary of these being command line editing). The Korn shell
became very popular but had one major problem, unlike the rest of UNIX it
wasn't free, you had to pay AT&T for it.
Into this gap GNU launched bash (Bourne again shell), this like the Korn
Shell was based upon the Bourne shell language and like the Korn Shell it
also pinched features from the C Shell and other operating systems (in my
opinion in 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 made to be just like the Bourne shell), and is the most popular of
the free new generation shells.
With all this going on the C-Shell users started getting left out, that
was until tcsh came along. This added in all the extra features that
ksh/bash nicked from other operating systems on to the standard C-Shell it
also added in a much enhanced completion system, and fixed nearly all the
bugs that where present in the standard C-Shell (this still has some
fairly major bugs in it).
The search for the perfect shell still goes on and the latest entries into
this arena are zsh and rc. Zsh is a feature packed shell which has so many
features that I don't even think the author knows all of them. It is still
a little buggy, although the bugs are slowly being ironed out. Rc is a
shell which works under the principle of less is more, probably best for
scripts since it is rumoured to be very fast.
DECIDING ON A SHELL
Which of the many shells you choose depends on many different things, here
is what I consider to be the most important.
1) 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.
2) 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.
3) Do I have to be able to switch back to a different shell. If you may
have to switch back to a standard shell, it is fairly important you
don't become too dependant on extra features and so can't use an older
shell.
4) 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.
5) What support is given for my new shell. If your new shell is not
supported make sure you have someone you can ask if in problems or have
the time to sort them out yourself.
6) 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.
7) Can I afford any minor bugs. All shells have some bugs in them
(especially csh) can you afford the problems that may occur because of
them.
SHELL FEATURES (0)
sh csh ksh bash tcsh zsh rc
Job control N Y Y Y Y Y N
Aliases N Y Y Y Y Y N
Shell functions Y(1) N Y Y N Y Y
"Sensible" Input/Output redirection Y N Y Y N Y Y
Directory stack N Y Y Y Y Y N
Command history N Y Y Y Y Y N
Command line editing N N Y Y Y Y N(4)
Vi Command line editing N N Y Y Y(3) Y N
Emacs Command line editing N N Y Y Y Y N
Rebindable Command line editing N N N Y Y Y N
User name look up N Y Y Y Y Y N(4)
Login/Logout watching N N N N Y Y N
Filename completion N Y(1) Y Y Y Y N
Username completion N Y(2) Y Y Y Y N
Hostname completion N Y(2) Y Y Y Y N
History completion N N N N Y Y N
Fully programmable Completion N N N N Y Y N
Mh Mailbox completion N N N N(4) N(6) N(6) N
Co Processes N N Y N N Y N
Builtin artithmetic evaluation N Y Y Y Y Y N
Follow symbolic links N N N Y Y Y N
Periodic command execution N N N N Y Y N
Custom Prompt (easily) N N N Y Y Y Y
Sun Keyboard Hack N N N N N Y N
Spelling Correction N N N N Y Y N
Process Substitution N N N Y(2) N Y Y
Underlying Syntax sh csh sh sh csh sh rc
Freely Available N N N(5) Y Y Y Y
Checks Mailbox N Y Y Y Y Y N
Tty Sanity Checking N N ? N Y Y N
Can cope with large arguement lists Y N Y Y Y Y Y
Can avoid user startup files N N ? Y N Y N
Can specify start up file N N ? Y N N N
0 This table does not include every single possible feature for every
single possible shell, but it does include all the features that I
think would make you choose one shell over another. It is *not* a
definitive list.
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.
6 This can be done via the shells programmable completion mechanism.
HOW TO CHANGE YOUR SHELL
If you ever look a UNIX manual it will say that to change your shell use
chsh or passwd -s, unfortunately it normally isn't as simple as this,
since it requires that your new shell is recognised as a valid shell by
the system and at present most systems do not recognise the newer shells
(the normal selection is, /bin/sh, /bin/csh and possibly /bin/ksh). You
are thus left with having to do some sort of fudge, changing your
effective login shell without changing your official entry in /etc/passwd.
You may also be left with the problem that there isn't a compiled binary
on your system , so you will have to get hold of the shells source and
compile it yourself (Its generally best to ask around to see if anyones
done this already, since it isn't that easy. Once done you should add in
code to your old shells login file so that it overlays your official login
shell with your new shell (remember to add the login flags to the command
line, and with csh/tcsh ensure that the overlay doesn't happen recursively
since they both read the same .login file).
WARNING
If you do decide to change your shell you must be *very* careful, if
handled wrongly it can be almost impossible to correct, and will almost
certainly cause you alot of hassle. Never make a new shell a login shell
until you have tested its new configuration files thoroughly and then
tested them once again, it is also important that you make a full backup
of your previous config files onto a floppy disk (or a different host if
you have a second account) if you have to change any of them (which you
will probably have to do if you can't change your shell entry in /etc/passwd).
You should also note that your new shell is probably NOT supported by your
system admin, so if you have any problems you will probably have to look
elsewhere.
--
Brian Blackmore, Darwin College, The University of Kent at Canterbury, UK.
Beyond the shadow of a dream who knows what lies