From the page on unix operating systems, you know that a shell is a mediator between a user and the actual operating system or kernel. What is not immediately clear, or even useful, to new users is that a shell is also a programming language. A shell understands a syntax that includes various kinds of loops, as well as conditionals "if ... else if ... else", "case" for sh, "switch" for csh and the creating and setting of variables. A shell script knows: command line arguments, how to do arithmetic (sometimes indirectly), its own process number, how to deal with interrupts, all unix utilities, and can capture the exit status of a called utility. (Exit without error is generally 0 status; there is no convention for the exit status for exit with error. You'll have to check the manual section for the specific utility.) A shell understands a collection of metacharacters when functioning as a user interface or when interpreting a shell script. A shell script when run, like a user, also has environmental variables and a current working directory. If you have accessed your shell account , use the command
env
to see your own environmental variables.
A shell can redirect standard I/O with '>', '>>', '<', and '|'.
Shell scripts are written in files just like binaries but they are interpreted not compiled and therefore slower. When a copy of a shell process is called to interpret a script, it makes its own private copy of the file, reading and checking for syntax as it does so. The execution of the script is then effected by a sequential reading of this private copy. Because of this shell scripts can be written that 'learn', i.e., that edit and modify themselves or other shell scripts. This potential (very LISP-like) does not seem to be exploited very much. It is fairly routine for shell scripts to write shell scripts and then get another shell process to execute them. From within HTML, shell scripts can be executed that process information that is obtained from a FORM.
There are programs floating around that turn shell scripts into C-program
files that can then be compiled.
The code produced is, as to be expected, overblown, ugly,
probably unreadable and something which no programmer in his right
mind would ever write.
Nevertheless, shell scripts can be very powerful tools in their
own right and also used for prototyping a program that is conceived
of to run, eventually, as a compiled C program.
If you become good at it, shell code can do powerful things
in a quick and dirty way.
This aspect of shell as programming language will be
discussed in more detail elsewhere.
The original shell of UNIX was the Bourne shell whose program name is 'sh'. At first, sh did not support functions in its scripts so the code was all read in one big list of programming statements. About the time of "Unix System V", functions were added to the syntax of sh with no change in name. These functions, however, a more like "routines" since there is no concept of "local variables" for them, and they do not return values, they just return. All shell variables were global, and still are. There have been a small number of shells that have evolved since then that are "more powerful", providing more user and programing features. In approximate chronological order, they are:
sh "The Shell" or Bourne Shell
csh "The C Shell"
mash "The Massey Shell"
ksh "The Korn Shell" (with attached emacs editor)
vksh "The Korn Shell" (with attached vi editor)
bash "The Bourne Again Shell" or Enhanced Bourne Shell
tcsh "The enhanced C Shell"
All shells provide "environmental variables" whose values are things
like: your home directory, what terminal type you are using,
where to look for executable programs, the name of the file
where your incoming mail is put; a shell also provides a way,
natuarally, of setting such variables to appropriate values.
All shells have associated "startup files" where customizing
is written, and which are read by your shell process when you log in.
When csh was first introduced, it was significantly larger than sh,
and ran slower. The then slower machines made this a important
criterion in selection of shell.
Programmers and heavy unix users preferred the increased power
of csh for interactive work, but frequently used sh for the
writing of shell programs (a.k.a shell scripts).
The C shell, developed at Berkeley, is so called because of it C-like syntax when used as a programming language. It was thought that csh provided a greater unity and integrity to the overall unix system since C language permeates the entire unix concept. The utilities of unix and 90% of the kernel are written in C, and unix provides a wonderful working environment for the C programmer. This provision was one of the intended purposes of unix; the other is a text processing environment suitable for technical documents ranging from memos (hence a mail system) to entire books. The C shell added to the user interface a concept of 'history' or reference to list of previously issued commands. The length of the list, kept internally by csh can be set by the user. It also introduced the concept of command 'alias', which enabled a user to customize his own environment to reduce the number of keystrokes required to achieve a desired result; this is especially helpful when the same or similar commands are used repeatedly. The C shell has stuck around, and many of its features have been borrowed in the design of other shells.
The Massey Shell, never quite caught on and it now often unknown, even to unix people. I myself, have never used it, do not know its syntax and only know of its existence.
The Korn Shell, in both its incarnations, attempted to outdo the C shell in features, and introduced in the command history the idea of actually editing a previous command before it is once again executed; this is where the choice of vi or emacs comes in.
The "Bourne Again Shell", is revision of sh, that incorporates nicities of both csh and ksh, while maintaining backwards compatiblity; shell scripts that run under sh will, generally, also run under bash.
One of the little nemesis of going back and forth between sh and csh was that in the shell '!' is a semi-ordinary character (in sh logic, it is a negation operator), while in csh '!' is a metacharacter associated with the history mechanism. Unfortunately '!' also has special use in the context of Unix to Unix CoPy 'uucp' (original transmission mechanism for Usenet), serving as the "machine!machine" separator in the specification of transmission paths. (Yes, they had to be specified.)
Bash now uses '!' as its history related metacharacter just as csh does. Csh and bash are the two most often used interactive shells now, with, I think, bash predominating.
Manual sections for the available shells can be accessed in your shell account by the man command.