On Mon, May 11, 1998 at 01:35:37AM -0400, Thomas F. Maher, Jr. wrote:
> Linux seems to be using the "Bourne Again Shell", aka "bash", by default,
> but also seems to have the C shell installed, and possibly the Korn shell
> somewhere, I think...
>
> "Unix Shells By Example: The guide to the C, Bourne, and Korn Shell, Awk,
> Sed, and Grep" by Ellie Quigley (C) 1997 that the shell is the interface
> between the user and the "kernel", the "heart" of the OS, loaded into
> memory, at boot time, and when you type in commands, the shell parses the
> command line, handle the wildcards, pipes, and job control, searches for
> the command, and executes it. The Borne shell was based on Algol, and was
> first made by AT&T. It does mention that the Korn shell, named after the
> creator, David Korn, runs not only on Unix, but OS/2. Korn is a a superset
> of Bourne.... hrm... but it doesn't seem to mention where the Bourne Again
> Shell came from...
Steven R. Bourne wrote the Bourne shell, known as "sh".
The Berkeley boys -- in particular Bill Joy, now of Sun -- wrote the
C-shell, "csh", which borrowed some items from the C language.
The internal-to-AT&T followon to the Bourne shell was the Korn shell, ksh,
which as you pointed out, is named for its orginator.
However, unlike sh, whose sources were part of the v6, v7, 32V and other
Unix distributions, and csh, who sources were part of the BSD distributions,
the sources for ksh were *not* released, which meant that it was not
included in lots of folks' Unix distributions. A workalike known
as "pdksh" was around for a while, but I seem to have lost track of it.
The Bourne-again shell, bash, is a product of the GNU effort (like Emacs
and gcc and other programs). It's a superset of sh with lots of things
borrowed from ksh and a snobby attitude toward csh. ;-)
One correction to your explanation above: the shell is *not* loaded
in at boot time. It's perfectly possible to run fully-functional Unix
systems without a shell, although it does make command-line interaction
with the OS rather problematical. ;-)
What really happens is this:
1. The boot loader runs. This is a tiny little program that does what
jsut about all boot loaders do: copies the Unix kernel from disk into memory
and does a non-returning call to it.
2. The Unix kernel starts up and (depending on the version) allocates
memory buffers for its own use, does some hardware probing, perhaps
some optional device driver loading depending on what devices are
present.
3. The kernel starts 'init', the Father of all Processes. Under Unix
an instance of an executing program is called a "process". Right now,
I have several shells running, each in their own xterm window; I have
mutt (my mailer) running; and I have an instance of vi (editor) running.
Each process is created by some combination of fork() and exec()
systems calls from existing processes. In other words, every process
executing on a Unix system sits somewhere in a tree whose ultimate
top-level node is "init". How does init get started, with no predecessor
to fork() from? The kernel creates it out of whole cloth (so to speak).
Init is the only process thus created.
4. The kernel starts reading various scripts usually known generically
as "rc" scripts; under SunOS, for example, it read /etc/rc, /etc/rc.local.
As it turns out, these are Bourne shell scripts -- but they don't have
to be. They're used to start up various background processes ("daemons")
which do things like shuffle mail (sendmail), execute jobs scheduled
for a later date (cron, at), handle printers (lpd), shovel Usenet news
around (nntpd), do system logging (syslog), and so on. There is nothing
extraordinary about these processes: they are substantially the same as
my shell, mailer and editor that I mentioned in #2. It's just that most
of them run with root privileges and spend 99% of their time sleeping
waiting for something to do.
5. One of the last things that happens as part of #4 is that interactive
logins are enabled: on most systems, this means that getty starts
up on each physically connected tty line (and/or the console). This is
the program that prints out something like:
SunOS Release 4.1.4 (GSP) #1: Tue Jan 6 11:32:41 EST 1998
login:
and waits for someone to come along and talk to it. Once somebody does,
getty calls /bin/login to verify that the login name and password supplied
are legitimate; it then logs the user in to *whatever their login shell is*.
Sometimes that's sh, csh, ksh, or bash; but in some environments, users'
login shell is set to a particular application, so that when they log in,
they're immediately dropped into a closed environment that lets them run
one app and does *not* let them talk to a Unix shell. Sometimes this is
done for security reasons, sometimes it's done to make users' lives simpler.
6. Assuming that J. Random User's login shell is one of what we all
usually mean when we say "shell", they are now staring at a command-line
prompt. All of these shells let users do similar things:
- execute commands
cat foobar.c
sort blah
mail hosehead
- redirect I/O to/from files
cat foobar.c > output-file
sort < blah > blah.sorted
- fit commands together with pipes
cat /etc/motd | mail hosehead
sort < blah | uniq > blah2
and so on. People have played with different kinds of shells, including
those that allowed for a richer pipe "|" syntax than the unidirectional
single-source, single-output pipes that most shells deal with; there have
been visual shells, perl shells, and even (and I like this one) the
Adventure Shell, which borrowed its syntax and semantics from a rather
well-known text-based computer game...
% go to bin
you are in ~jon/bin. there are many files here.
% look
you are in ~jon/bin. the directory contains:
date
date.c
readtape
scramble
the only exit is up.
% use date to create tmp
done!
% take tmp
taken.
% open tmp
you open tmp to reveal:
Tue. November 24, 1981 (2:00pm EST)
% take date.c
taken.
% look
you are in ~jon/bin. the directory contains:
date
readtape
scramble
the only exit is up.
% inventory
you are carrying:
date.c
tmp
% goto src
you are in ~jon/src. there are many files here.
% drop date.c
dropped.
% throw tmp at printer
the printer catches your file, turns it into paper, and
leaves it in the basement.
% look
your are in ~jon/src. the directory contains:
date.c
scramble.c
readtape.c
there are exits marked 'zshell' and 'secret'
as well as the path leading up.
% xyzzy
you are back in your home directory. there are many files here.
% run foo
the foo dumps core.
Oh dear! you seem to have gotten yourself killed.
% attack core with sdb
...
Credit for this should go to Phil Reed, who sent this to User-Friendlies
back on Wed. 12/09/81, and to Gene Spafford, who forwarded it to me.
---Rsk
Rich Kulawiec
[EMAIL PROTECTED]
____________________________________________________________________
--------------------------------------------------------------------
Join The Web Consultants Association : Register on our web site Now
Web Consultants Web Site : http://just4u.com/webconsultants
If you lose the instructions All subscription/unsubscribing can be done
directly from our website for all our lists.
---------------------------------------------------------------------
