1 .\" This module is believed to contain source code proprietary to AT&T.
2 .\" Use and redistribution is subject to the Berkeley Software License
3 .\" Agreement and your Software Agreement with AT&T (Western Electric).
5 .\" @(#)p4 8.1 (Berkeley) 6/8/93
14 is carried on with the
15 aid of a program called the \&shell.
17 command-line interpreter: it reads lines typed by the user and
18 interprets them as requests to execute
20 (The \&shell is described fully elsewhere,
25 so this section will discuss only the theory of its operation.)
26 In simplest form, a command line consists of the command
27 name followed by arguments to the command, all separated
30 command arg\*s\d1\u\*n arg\*s\d2\u\*n .\|.\|. arg\*s\dn\u\*n
32 The \&shell splits up the command name and the arguments into
38 may be a path name including the ``/'' character to
39 specify any file in the system.
42 is found, it is brought into
45 collected by the \&shell are accessible
47 When the command is finished, the \&shell
48 resumes its own execution, and indicates its readiness
49 to accept another command by typing a prompt character.
54 the \&shell generally prefixes a string
60 attempts again to find the file.
64 intended to be generally used.
65 (The sequence of directories to be searched
66 may be changed by user request.)
70 The discussion of I/O in Section III above seems to imply that
71 every file used by a program must be opened or created by the program in
72 order to get a file descriptor for the file.
73 Programs executed by the \&shell, however, start off with
74 three open files with file descriptors
76 As such a program begins execution, file 1 is open for writing,
77 and is best understood as the standard output file.
78 Except under circumstances indicated below, this file
79 is the user's terminal.
80 Thus programs that wish to write informative
81 information ordinarily use file descriptor 1.
82 Conversely, file 0 starts off open for reading, and programs that
83 wish to read messages typed by the user
86 The \&shell is able to change the standard assignments of
87 these file descriptors from the
88 user's terminal printer and keyboard.
90 arguments to a command is prefixed by ``>'', file descriptor
91 1 will, for the duration of the command, refer to the
92 file named after the ``>''.
97 ordinarily lists, on the typewriter, the names of the files in the current
103 creates a file called
105 and places the listing there.
115 ordinarily enters the editor, which takes requests from the
116 user via his keyboard.
123 as a file of editor commands;
126 means ``take input from
129 Although the file name following ``<'' or ``>'' appears
130 to be an argument to the command, in fact it is interpreted
131 completely by the \&shell and is not passed to the
133 Thus no special coding to handle I/O redirection is needed within each
134 command; the command need merely use the standard file
135 descriptors 0 and 1 where appropriate.
137 File descriptor 2 is, like file 1,
138 ordinarily associated with the terminal output stream.
139 When an output-diversion request with ``>'' is specified,
140 file 2 remains attached to the terminal, so that commands
141 may produce diagnostic messages that
142 do not silently end up in the output file.
146 An extension of the standard I/O notion is used
147 to direct output from one command to
148 the input of another.
149 A sequence of commands separated by
150 vertical bars causes the \&shell to
151 execute all the commands simultaneously and to arrange
152 that the standard output of each command
153 be delivered to the standard input of
154 the next command in the sequence.
155 Thus in the command line:
160 lists the names of the files in the current directory;
161 its output is passed to
164 paginates its input with dated headings.
165 (The argument ``\(mi2'' requests
166 double-column output.)
167 Likewise, the output from
171 this command spools its input onto a file for off-line
174 This procedure could have been carried out
178 pr \(mi2 <temp1 >temp2
181 followed by removal of the temporary files.
182 In the absence of the ability
183 to redirect output and input,
184 a still clumsier method would have been to
188 to accept user requests to paginate its output,
189 to print in multi-column format, and to arrange
190 that its output be delivered off-line.
191 Actually it would be surprising, and in fact
192 unwise for efficiency reasons,
196 to provide such a wide variety of output options.
201 which copies its standard input to its standard output
205 Some filters that we have found useful
207 character transliteration,
208 selection of lines according to a pattern,
209 sorting of the input,
210 and encryption and decryption.
212 6.3 Command separators; multitasking
214 Another feature provided by the \&shell is relatively straightforward.
215 Commands need not be on different lines; instead they may be separated
220 will first list the contents of the current directory, then enter
223 A related feature is more interesting.
224 If a command is followed
225 by ``\f3&\f1,'' the \&shell will not wait for the command to finish before
226 prompting again; instead, it is ready immediately
227 to accept a new command.
235 to be assembled, with diagnostic
238 no matter how long the
239 assembly takes, the \&shell returns immediately.
240 When the \&shell does not wait for
241 the completion of a command,
242 the identification number of the
243 process running that command is printed.
244 This identification may be used to
245 wait for the completion of the command or to
247 The ``\f3&\f1'' may be used
248 several times in a line:
250 as source >output & ls >files &
252 does both the assembly and the listing in the background.
253 In these examples, an output file
254 other than the terminal was provided; if this had not been
255 done, the outputs of the various commands would have been
258 The \&shell also allows parentheses in the above operations.
263 writes the current date and time followed by
264 a list of the current directory onto the file
266 The \&shell also returns immediately for another request.
268 6.4 The \&shell as a command; command files
270 The \&shell is itself a command, and may be called recursively.
281 command causes the file
286 is the (binary) output of the assembler, ready to be executed.
287 Thus if the three lines above were typed on the keyboard,
289 would be assembled, the resulting program renamed
294 When the lines are in
300 would cause the \&shell
302 to execute the commands
305 The \&shell has further capabilities, including the
306 ability to substitute parameters
308 to construct argument lists from a specified
309 subset of the file names in a directory.
310 It also provides general conditional and looping constructions.
312 6.5 Implementation of the \&shell
314 The outline of the operation of the \&shell can now be understood.
315 Most of the time, the \&shell
316 is waiting for the user to type a command.
318 newline character ending the line
319 is typed, the \&shell's
322 The \&shell analyzes the command line, putting the
323 arguments in a form appropriate for
328 The child process, whose code
329 of course is still that of the \&shell, attempts
332 with the appropriate arguments.
333 If successful, this will bring in and start execution of the program whose name
335 Meanwhile, the other process resulting from the
340 for the child process to die.
341 When this happens, the \&shell knows the command is finished, so
342 it types its prompt and reads the keyboard to obtain another
345 Given this framework, the implementation of background processes
346 is trivial; whenever a command line contains ``\f3&\f1,''
347 the \&shell merely refrains from waiting for the process
349 to execute the command.
351 Happily, all of this mechanism meshes very nicely with
352 the notion of standard input and output files.
353 When a process is created by the
356 inherits not only the memory image of its parent
357 but also all the files currently open in its parent,
358 including those with file descriptors 0, 1, and 2.
359 The \&shell, of course, uses these files to read command
360 lines and to write its prompts and diagnostics, and in the ordinary case
361 its children\(emthe command programs\(eminherit them automatically.
362 When an argument with ``<'' or ``>'' is given, however, the
363 offspring process, just before it performs
365 makes the standard I/O
366 file descriptor (0 or 1, respectively) refer to the named file.
368 because, by agreement,
369 the smallest unused file descriptor is assigned
374 it is only necessary to close file 0 (or 1)
375 and open the named file.
376 Because the process in which the command program runs simply terminates
377 when it is through, the association between a file
378 specified after ``<'' or ``>'' and file descriptor 0 or 1 is ended
379 automatically when the process dies.
381 the \&shell need not know the actual names of the files
382 that are its own standard input and output, because it need
385 Filters are straightforward extensions
386 of standard I/O redirection with pipes used
389 In ordinary circumstances, the main loop of the \&shell never
391 (The main loop includes the
392 branch of the return from
395 parent process; that is, the branch that does a
398 reads another command line.)
399 The one thing that causes the \&shell to terminate is
400 discovering an end-of-file condition on its input file.
401 Thus, when the \&shell is executed as a command with
402 a given input file, as in:
408 will be executed until
411 is reached; then the instance of the \&shell
415 Because this \&shell process
416 is the child of another instance of the \&shell, the
418 executed in the latter will return, and another
419 command may then be processed.
423 The instances of the \&shell to which users type
424 commands are themselves children of another process.
425 The last step in the initialization of
428 a single process and the invocation (via
434 is to create one process
435 for each terminal channel.
436 The various subinstances of
438 open the appropriate terminals
440 on files 0, 1, and 2,
441 waiting, if necessary, for carrier to be established on dial-up lines.
442 Then a message is typed out requesting that the user log in.
443 When the user types a name or other identification,
444 the appropriate instance of
446 wakes up, receives the log-in
447 line, and reads a password file.
448 If the user's name is found, and if
449 he is able to supply the correct password,
451 changes to the user's default current directory, sets
452 the process's user \*sID\*n to that of the person logging in, and performs
456 At this point, the \&shell is ready to receive commands
457 and the logging-in protocol is complete.
459 Meanwhile, the mainstream path of
462 the subinstances of itself that will later become \&shells)
465 If one of the child processes terminates, either
466 because a \&shell found an end of file or because a user
467 typed an incorrect name or password, this path of
469 simply recreates the defunct process, which in turn reopens the appropriate
470 input and output files and types another log-in message.
471 Thus a user may log out simply by typing the end-of-file
472 sequence to the \&shell.
474 6.7 Other programs as \&shell
476 The \&shell as described above is designed to allow users
477 full access to the facilities of the system, because it will
478 invoke the execution of any program
479 with appropriate protection mode.
480 Sometimes, however, a different interface to the system
481 is desirable, and this feature is easily arranged for.
483 Recall that after a user has successfully logged in by supplying
486 ordinarily invokes the \&shell
487 to interpret command lines.
489 in the password file may contain the name
490 of a program to be invoked after log-in instead of the \&shell.
491 This program is free to interpret the user's messages
492 in any way it wishes.
494 For example, the password file entries
495 for users of a secretarial editing system
500 is to be used instead of the \&shell.
501 Thus when users of the editing system log in, they are inside the editor and
502 can begin work immediately; also, they can be prevented from
504 programs not intended for their use.
505 In practice, it has proved desirable to allow a temporary
506 escape from the editor
507 to execute the formatting program and other utilities.
509 Several of the games (e.g., chess, blackjack, 3D tic-tac-toe)
513 a much more severely restricted environment.
514 For each of these, an entry exists
515 in the password file specifying that the appropriate game-playing
516 program is to be invoked instead of the \&shell.
517 People who log in as a player
518 of one of these games find themselves limited to the
519 game and unable to investigate the (presumably more interesting)