Different Kinds of Shells
The great-grandfather of all shells is /bin/sh, called simply sh or the
Bourne Shell, named after its developer, Steven Bourne. When it was first
introduced in the mid-1970s, this was almost a godsend as it allowed
interaction with the operating system.
This is the "standard" shell that you will find on every version in UNIX
(at least all those I have seen). Although many changes have been made to
UNIX, sh has remained basically unchanged.
All the capabilities of "the shell"
I've talked about so far apply to sh.
Anything I've talked about that sh can do, the others can do as well. So rather
than going on about what sh can do (which I already did), I am going to talk
about the characteristics of some other shells.
Later, I am going to talk about the C-Shell, which kind of throws a monkey
wrench into this entire discussion. Although the concepts are much the same
between the C-Shell and other shells, the constructs are often quite different.
On the other hand, the other shells are extensions of the Bourne Shell, so the
syntax and constructs are basically the same.
Be careful here. This is one case in which I have noticed that the various
versions of Linux are different. Not every shell
is in every version. Therefore,
the shells I am going to talk about may not be in your distribution. Have no
fear! If there is a feature that you really like, you can either take the source
code from one of the other shells and add it or you can find the different
shells all over the Internet, which is much easier.
Linux includes several different shells and we will get into the specific of many
of them as we move along. In addition, many different shells are available
as either public domain, shareware, or commercial products that you can install
As I mentioned earlier, environment
variables are set up for you as you are
logging in or you can set them up later. Depending on the shell
you use, the files used and where they are located is going to be different. Some variables
are made available to everyone on the system and are accessed through a common
file. Others reside in the user's home directory.
Normally, the files residing in a users home directory
can be modified.
However, a system administrator
may wish to prevent users from doing so. Often,
menus are set up in these files to either make things easier for the user or to
prevent the user from getting to the command line.
(Often users never need to get that far.) In other cases, environment
variables that shouldn't be changed need to be set up for the user.
One convention I will be using here is how I refer to the different shells.
Often, I will say "the bash" or just "bash" to refer to the Bourne-Again Shell
as a concept and not the program /bin/bash. I will use "bash" to refer to the
"Bourne Shell" as an abstract entity and not specifically to the program
Why the Bourne-Again Shell? Well, this shell
is compatible with the Bourne
Shell, but has many of the same features as both the Korn Shell (ksh) and
C-Shell (csh). This is especially important to me as I flail violently when I
don't have a Korn Shell.
Most of the issues I am going to address here are detailed in the
appropriate man-pages and other documents. Why cover them here? Well, in keeping
with one basic premise of this book, I want to show you the relationships
involved. In addition, many of the things we are going to look at are not
emphasized as much as they should be. Often, users will go for months or years
without learning the magic that these shells can do.
Only one oddity really needs to be addressed: the behavior of the different
shells when moving through symbolic links. As I mentioned before, symbolic links
are simply pointers to files or directories elsewhere on the system. If you
change directories into symbolic links, your "location" on the disk is different
than what you might think. In some cases, the shell
understands the distinction
and hides from you the fact that you are somewhere else. This is where the
Although the concept of a symbolic link
exists in most versions of UNIX,
is a relatively new aspect. As a result, not all applications and programs
behave in the same way. Let's take the directory /usr/spool as an example.
Because it contains a lot of administrative information, it is a useful and
commonly accessed directory. It is actually a symbolic link
to /var/spool. If we
are using ash as our shell,
when we do a cd /usr/spool and then pwd, the system
responds with: /var/spool. This is where we are "physically" located, despite
the fact that we did a
If we use bash, things are different. This time, when we do a cd /usr/spool
and then pwd, the system responds with /usr/spools. This is where we are
"logically". If we now do a cd .., we are located in /usr. Which of these is the
"correct" behavior? Well, I would say both. There is nothing to define
what the "correct" behavior is. Depending on your preference, either is correct.
I tend to prefer the behavior of ksh. However, the behavior of ash is also