ftp.disi.unige.it/2015-02-11.ftp.disi.unige.it.tar/ftp.disi.unige.it/pub/.person/GianuzziV/SysOp/shell.txt

Text File | 1996-11-21 | 16KB | 292 lines

        UNIX SHELL DIFFERENCES AND HOW TO CHANGE YOUR SHELL
              Brian Blackmore, [e-mail]

           Archive-name: unix-faq/shell/shell-differences

                           Version: 1.06

----------------------------------------------------------------------------

Contents

   * Modifications since last issue
   * Why change your shell
   * The history of unix shells
   * Deciding on a shell
   * Shell features (table)
   * How to change your shell
   * A warning about changing your shell
   * Further information
   * Copyright and Disclaimer

----------------------------------------------------------------------------

MODIFICATIONS SINCE LAST ISSUE

I have a new email address, and from around the end of July my old address
will be no more. Email relating to the content of this document should now
be sent to [e-mail], while any other email should be
sent to [e-mail].

----------------------------------------------------------------------------

WHY CHANGE YOUR SHELL

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 (e.g. showing
your directory in your prompt, showing which files it would complete) and
they cover some of the more annoying 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 has 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 were 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 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, TENEX-style
completion and several other features. Out went most of the bugs, but did
the various UNIX operating system manufacturers start shipping tcsh instead
of csh? No, they stuck with the standard C-Shell.

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 other operating. 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 standard. POSIX specified more or less the
System V Bourne Shell (by this time the BSD 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 bash (the Bourne again shell) 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.

Meanwhile faced with the problem of porting the Bourne shell to Plan 9, Tom
Duff revolts and writes rc, he publishes a paper on it, and Byron Rakitzis
reimplements it under UNIX. Rc ended up smalled, simpler, more regular and
in most peoples opinion a much better programmed shell.

The search for the perfect shell still goes on and the latest entry into
this arena is zsh. Zsh was written by Paul Falstad while he was a student a
Princeton and is a feature packed shell which has so many features that I
don't even think the he even knows all of them.

----------------------------------------------------------------------------

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, 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.
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 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 dependent on extra features and so can't
     use an older shell.
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.
     This only really applies to very old systems nowadays.
What support is given for my new shell?
     If your new shell is not supported 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.

----------------------------------------------------------------------------

SHELL FEATURES

This table below lists most features that I think would make you 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.

                                        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(7)
Command line editing                    N    N     Y    Y    Y    Y    N(7)
Vi Command line editing                 N    N     Y    Y    Y(3) Y    N(7)
Emacs Command line editing              N    N     Y    Y    Y    Y    N(7)
Rebindable Command line editing         N    N     N    Y    Y    Y    N(7)
User name look up                       N    Y     Y    Y    Y    Y    N(7)
Login/Logout watching                   N    N     N    N    Y    Y    N
Filename completion                     N    Y(1)  Y    Y    Y    Y    N(7)
Username completion                     N    Y(2)  Y    Y    Y    Y    N(7)
Hostname completion                     N    Y(2)  Y    Y    Y    Y    N(7)
History completion                      N    N     N    Y    Y    Y    N(7)
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
Can follow symbolic links               N    N     Y    Y    Y    Y    N
Periodic command execution              N    N     N    N    Y    Y    N
Custom Prompt (easily)                  N    N     Y    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(8)
Tty Sanity Checking                     N    N     N    N    Y    Y    N
Can cope with large argument lists      Y    N     Y    Y    Y    Y    Y
Has non-interactive startup file        N    Y     Y(9) Y(9) Y    Y    N
Has non-login startup file              N    Y     Y(9) Y    Y    Y    N
Can avoid user startup files            N    N     N    Y    N    Y    Y
Can specify startup file                N    N     Y    Y    N    N    N

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. A library can be linked into the shell to provide this feature.
  8. This can be done via the shells prompt function.
  9. Only by specifing a file via the ENV environment variable.

----------------------------------------------------------------------------

HOW TO CHANGE YOUR SHELL

If you ever look at a UNIX manual page it will say that to change your shell
use chsh or passwd -s; unfortunately it often isn't as simple as this, since
it requires that your new shell is recognized as a valid shell by the system
and at present many systems do not recognize 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 shell's 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).

The shell can be recognized as a valid shell if the system administrator
puts it in the file /etc/shells. If this file does not exist, it must be
created and should contain all valid shells (i.e.don't forget the
traditional ones in all their forms).

----------------------------------------------------------------------------

A WARNING ABOUT CHANGING YOUR SHELL

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 a lot 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.

----------------------------------------------------------------------------

FURTHER INFORMATION

The Bourne shell, the C-Shell and the Korn Shell (if you have it) are all
distributed as standard with your UNIX operating system, information on
these should come with your operating system, bug reports etc should be sent
to your operating system vendor.

Bash was written and is maintained by the Free Software Foundation, the
primary source of information for this shell is its manual page. Bug reports
should be sent to [e-mail], while suggestions and
philosophical bug reports may be mailed to [e-mail] or posted to
the Usenet newsgroup gnu.bash.bug, the source is widely available on many
ftp sites, and is subject to the GNU copyleft licence.

Rc is available by ftp from ftp:viz.tamu.edu/pub/rc and several other
places. An FAQ exists and is posted frequently to comp.unix.shell and other
places. The Rc mailing list may be subscribed to by sending mail to
[e-mail], this, the manual page and the Rc FAQ
are the main sources of information for this shell.

Zsh is now maintained by the zsh mailing list, which can be subscribed to by
sending email to [e-mail] containing subscribe zsh-list, there
is also an FAQ which is posted frequently to comp.unix.shell. The manual
page, the Z-shell FAQ and the zsh-list are the main sources of information
for this shell.

Questions on any of the UNIX shells and on shell script programming, may be
posted to the Usenet newsgroup comp.unix.shell a quick response can normally
be expected, especially on subjects relating to the more common shells.