aid of a program called the \&shell.
command-line interpreter: it reads lines typed by the user and
interprets them as requests to execute
(The \&shell is described fully elsewhere,
so this section will discuss only the theory of its operation.)
In simplest form, a command line consists of the command
name followed by arguments to the command, all separated
command arg\*s\d1\u\*n arg\*s\d2\u\*n .\|.\|. arg\*s\dn\u\*n
The \&shell splits up the command name and the arguments into
may be a path name including the ``/'' character to
specify any file in the system.
is found, it is brought into
collected by the \&shell are accessible
When the command is finished, the \&shell
resumes its own execution, and indicates its readiness
to accept another command by typing a prompt character.
the \&shell generally prefixes a string
attempts again to find the file.
intended to be generally used.
(The sequence of directories to be searched
may be changed by user request.)
The discussion of I/O in Section III above seems to imply that
every file used by a program must be opened or created by the program in
order to get a file descriptor for the file.
Programs executed by the \&shell, however, start off with
three open files with file descriptors
As such a program begins execution, file 1 is open for writing,
and is best understood as the standard output file.
Except under circumstances indicated below, this file
Thus programs that wish to write informative
information ordinarily use file descriptor 1.
Conversely, file 0 starts off open for reading, and programs that
wish to read messages typed by the user
The \&shell is able to change the standard assignments of
these file descriptors from the
user's terminal printer and keyboard.
arguments to a command is prefixed by ``>'', file descriptor
1 will, for the duration of the command, refer to the
file named after the ``>''.
ordinarily lists, on the typewriter, the names of the files in the current
and places the listing there.
ordinarily enters the editor, which takes requests from the
as a file of editor commands;
Although the file name following ``<'' or ``>'' appears
to be an argument to the command, in fact it is interpreted
completely by the \&shell and is not passed to the
Thus no special coding to handle I/O redirection is needed within each
command; the command need merely use the standard file
descriptors 0 and 1 where appropriate.
File descriptor 2 is, like file 1,
ordinarily associated with the terminal output stream.
When an output-diversion request with ``>'' is specified,
file 2 remains attached to the terminal, so that commands
may produce diagnostic messages that
do not silently end up in the output file.
An extension of the standard I/O notion is used
to direct output from one command to
A sequence of commands separated by
vertical bars causes the \&shell to
execute all the commands simultaneously and to arrange
that the standard output of each command
be delivered to the standard input of
the next command in the sequence.
Thus in the command line:
lists the names of the files in the current directory;
paginates its input with dated headings.
(The argument ``\(mi2'' requests
Likewise, the output from
this command spools its input onto a file for off-line
This procedure could have been carried out
followed by removal of the temporary files.
In the absence of the ability
to redirect output and input,
a still clumsier method would have been to
to accept user requests to paginate its output,
to print in multi-column format, and to arrange
that its output be delivered off-line.
Actually it would be surprising, and in fact
unwise for efficiency reasons,
to provide such a wide variety of output options.
which copies its standard input to its standard output
Some filters that we have found useful
character transliteration,
selection of lines according to a pattern,
and encryption and decryption.
6.3 Command separators; multitasking
Another feature provided by the \&shell is relatively straightforward.
Commands need not be on different lines; instead they may be separated
will first list the contents of the current directory, then enter
A related feature is more interesting.
by ``\f3&\f1,'' the \&shell will not wait for the command to finish before
prompting again; instead, it is ready immediately
to be assembled, with diagnostic
assembly takes, the \&shell returns immediately.
When the \&shell does not wait for
the completion of a command,
the identification number of the
process running that command is printed.
This identification may be used to
wait for the completion of the command or to
The ``\f3&\f1'' may be used
as source >output & ls >files &
does both the assembly and the listing in the background.
In these examples, an output file
other than the terminal was provided; if this had not been
done, the outputs of the various commands would have been
The \&shell also allows parentheses in the above operations.
writes the current date and time followed by
a list of the current directory onto the file
The \&shell also returns immediately for another request.
6.4 The \&shell as a command; command files
The \&shell is itself a command, and may be called recursively.
is the (binary) output of the assembler, ready to be executed.
Thus if the three lines above were typed on the keyboard,
would be assembled, the resulting program renamed
The \&shell has further capabilities, including the
ability to substitute parameters
to construct argument lists from a specified
subset of the file names in a directory.
It also provides general conditional and looping constructions.
6.5 Implementation of the \&shell
The outline of the operation of the \&shell can now be understood.
Most of the time, the \&shell
is waiting for the user to type a command.
newline character ending the line
The \&shell analyzes the command line, putting the
arguments in a form appropriate for
The child process, whose code
of course is still that of the \&shell, attempts
with the appropriate arguments.
If successful, this will bring in and start execution of the program whose name
Meanwhile, the other process resulting from the
for the child process to die.
When this happens, the \&shell knows the command is finished, so
it types its prompt and reads the keyboard to obtain another
Given this framework, the implementation of background processes
is trivial; whenever a command line contains ``\f3&\f1,''
the \&shell merely refrains from waiting for the process
Happily, all of this mechanism meshes very nicely with
the notion of standard input and output files.
When a process is created by the
inherits not only the memory image of its parent
but also all the files currently open in its parent,
including those with file descriptors 0, 1, and 2.
The \&shell, of course, uses these files to read command
lines and to write its prompts and diagnostics, and in the ordinary case
its children\(emthe command programs\(eminherit them automatically.
When an argument with ``<'' or ``>'' is given, however, the
offspring process, just before it performs
file descriptor (0 or 1, respectively) refer to the named file.
the smallest unused file descriptor is assigned
it is only necessary to close file 0 (or 1)
Because the process in which the command program runs simply terminates
when it is through, the association between a file
specified after ``<'' or ``>'' and file descriptor 0 or 1 is ended
automatically when the process dies.
the \&shell need not know the actual names of the files
that are its own standard input and output, because it need
Filters are straightforward extensions
of standard I/O redirection with pipes used
In ordinary circumstances, the main loop of the \&shell never
(The main loop includes the
branch of the return from
parent process; that is, the branch that does a
reads another command line.)
The one thing that causes the \&shell to terminate is
discovering an end-of-file condition on its input file.
Thus, when the \&shell is executed as a command with
a given input file, as in:
is reached; then the instance of the \&shell
Because this \&shell process
is the child of another instance of the \&shell, the
executed in the latter will return, and another
command may then be processed.
The instances of the \&shell to which users type
commands are themselves children of another process.
The last step in the initialization of
a single process and the invocation (via
for each terminal channel.
The various subinstances of
open the appropriate terminals
waiting, if necessary, for carrier to be established on dial-up lines.
Then a message is typed out requesting that the user log in.
When the user types a name or other identification,
the appropriate instance of
wakes up, receives the log-in
line, and reads a password file.
If the user's name is found, and if
he is able to supply the correct password,
changes to the user's default current directory, sets
the process's user \*sID\*n to that of the person logging in, and performs
At this point, the \&shell is ready to receive commands
and the logging-in protocol is complete.
Meanwhile, the mainstream path of
the subinstances of itself that will later become \&shells)
If one of the child processes terminates, either
because a \&shell found an end of file or because a user
typed an incorrect name or password, this path of
simply recreates the defunct process, which in turn reopens the appropriate
input and output files and types another log-in message.
Thus a user may log out simply by typing the end-of-file
6.7 Other programs as \&shell
The \&shell as described above is designed to allow users
full access to the facilities of the system, because it will
invoke the execution of any program
with appropriate protection mode.
Sometimes, however, a different interface to the system
is desirable, and this feature is easily arranged for.
Recall that after a user has successfully logged in by supplying
ordinarily invokes the \&shell
to interpret command lines.
in the password file may contain the name
of a program to be invoked after log-in instead of the \&shell.
This program is free to interpret the user's messages
For example, the password file entries
for users of a secretarial editing system
is to be used instead of the \&shell.
Thus when users of the editing system log in, they are inside the editor and
can begin work immediately; also, they can be prevented from
programs not intended for their use.
In practice, it has proved desirable to allow a temporary
to execute the formatting program and other utilities.
Several of the games (e.g., chess, blackjack, 3D tic-tac-toe)
a much more severely restricted environment.
For each of these, an entry exists
in the password file specifying that the appropriate game-playing
program is to be invoked instead of the \&shell.
People who log in as a player
of one of these games find themselves limited to the
game and unable to investigate the (presumably more interesting)