GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive:programming:shell_history

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 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 a lot less 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 was 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, publishes a paper on it, and Byron
 Rakitzis reimplements it under UNIX. Rc ended up smaller, simpler, more
 regular and in most people's 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 that 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.
 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 completely 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; it's 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 dependent 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 you encounter
    problems or that you 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(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    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
 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
 Can avoid user startup files            N    N     N    Y    N    Y    N
 Can specify start up file               N    N     Y    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, 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.
 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 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 anyone has
 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).
 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 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 bash-maintainers@ai.MIT.Edu, while
 Suggestions and `philosophical' bug reports may be mailed to
 bug-bash@ai.MIT.Edu 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 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 rc-request@hawkwind.utcs.toronto.edu, 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 Majordomo@sterling.com 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.
/data/webs/external/dokuwiki/data/pages/archive/programming/shell_history.txt · Last modified: 1999/08/03 05:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki