![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to p4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps2 / 01.cacm|
Return to p4 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps2 / 01.cacm |
1.1 root 1: .\" @(#)p4 6.1 (Berkeley) 4/24/86
2: .\"
3: .SH
4: VI. THE SHELL
5: .PP
6: For most users,
7: communication with
8: the system
9: is carried on with the
10: aid of a program called the \&shell.
11: The \&shell is a
12: command-line interpreter: it reads lines typed by the user and
13: interprets them as requests to execute
14: other programs.
15: (The \&shell is described fully elsewhere,
16: .[
17: bourne shell bstj
18: %Q This issue
19: .]
20: so this section will discuss only the theory of its operation.)
21: In simplest form, a command line consists of the command
22: name followed by arguments to the command, all separated
23: by spaces:
24: .P1
25: command arg\*s\d1\u\*n arg\*s\d2\u\*n .\|.\|. arg\*s\dn\u\*n
26: .P2
27: The \&shell splits up the command name and the arguments into
28: separate strings.
29: Then a file with name
30: .UL command
31: is sought;
32: .UL command
33: may be a path name including the ``/'' character to
34: specify any file in the system.
35: If
36: .UL command
37: is found, it is brought into
38: memory and executed.
39: The arguments
40: collected by the \&shell are accessible
41: to the command.
42: When the command is finished, the \&shell
43: resumes its own execution, and indicates its readiness
44: to accept another command by typing a prompt character.
45: .PP
46: If file
47: .UL command
48: cannot be found,
49: the \&shell generally prefixes a string
50: such as
51: .UL /\|bin\|/
52: to
53: .UL command
54: and
55: attempts again to find the file.
56: Directory
57: .UL /\|bin
58: contains commands
59: intended to be generally used.
60: (The sequence of directories to be searched
61: may be changed by user request.)
62: .SH
63: 6.1 Standard I/O
64: .PP
65: The discussion of I/O in Section III above seems to imply that
66: every file used by a program must be opened or created by the program in
67: order to get a file descriptor for the file.
68: Programs executed by the \&shell, however, start off with
69: three open files with file descriptors
70: 0, 1, and 2.
71: As such a program begins execution, file 1 is open for writing,
72: and is best understood as the standard output file.
73: Except under circumstances indicated below, this file
74: is the user's terminal.
75: Thus programs that wish to write informative
76: information ordinarily use file descriptor 1.
77: Conversely, file 0 starts off open for reading, and programs that
78: wish to read messages typed by the user
79: read this file.
80: .PP
81: The \&shell is able to change the standard assignments of
82: these file descriptors from the
83: user's terminal printer and keyboard.
84: If one of the
85: arguments to a command is prefixed by ``>'', file descriptor
86: 1 will, for the duration of the command, refer to the
87: file named after the ``>''.
88: For example:
89: .P1
90: ls
91: .P2
92: ordinarily lists, on the typewriter, the names of the files in the current
93: directory.
94: The command:
95: .P1
96: ls >there
97: .P2
98: creates a file called
99: .UL there
100: and places the listing there.
101: Thus the argument
102: .UL >there
103: means
104: ``place output on
105: .UL there .''
106: On the other hand:
107: .P1
108: ed
109: .P2
110: ordinarily enters the editor, which takes requests from the
111: user via his keyboard.
112: The command
113: .P1
114: ed <script
115: .P2
116: interprets
117: .UL script
118: as a file of editor commands;
119: thus
120: .UL <script
121: means ``take input from
122: .UL script .''
123: .PP
124: Although the file name following ``<'' or ``>'' appears
125: to be an argument to the command, in fact it is interpreted
126: completely by the \&shell and is not passed to the
127: command at all.
128: Thus no special coding to handle I/O redirection is needed within each
129: command; the command need merely use the standard file
130: descriptors 0 and 1 where appropriate.
131: .PP
132: File descriptor 2 is, like file 1,
133: ordinarily associated with the terminal output stream.
134: When an output-diversion request with ``>'' is specified,
135: file 2 remains attached to the terminal, so that commands
136: may produce diagnostic messages that
137: do not silently end up in the output file.
138: .SH
139: 6.2 Filters
140: .PP
141: An extension of the standard I/O notion is used
142: to direct output from one command to
143: the input of another.
144: A sequence of commands separated by
145: vertical bars causes the \&shell to
146: execute all the commands simultaneously and to arrange
147: that the standard output of each command
148: be delivered to the standard input of
149: the next command in the sequence.
150: Thus in the command line:
151: .P1
152: ls | pr \(mi2 | opr
153: .P2
154: .UL ls
155: lists the names of the files in the current directory;
156: its output is passed to
157: .UL pr ,
158: which
159: paginates its input with dated headings.
160: (The argument ``\(mi2'' requests
161: double-column output.)
162: Likewise, the output from
163: .UL pr
164: is input to
165: .UL opr ;
166: this command spools its input onto a file for off-line
167: printing.
168: .PP
169: This procedure could have been carried out
170: more clumsily by:
171: .P1
172: ls >temp1
173: pr \(mi2 <temp1 >temp2
174: opr <temp2
175: .P2
176: followed by removal of the temporary files.
177: In the absence of the ability
178: to redirect output and input,
179: a still clumsier method would have been to
180: require the
181: .UL ls
182: command
183: to accept user requests to paginate its output,
184: to print in multi-column format, and to arrange
185: that its output be delivered off-line.
186: Actually it would be surprising, and in fact
187: unwise for efficiency reasons,
188: to expect authors of
189: commands such as
190: .UL ls
191: to provide such a wide variety of output options.
192: .PP
193: A program
194: such as
195: .UL pr
196: which copies its standard input to its standard output
197: (with processing)
198: is called a
199: .IT filter .
200: Some filters that we have found useful
201: perform
202: character transliteration,
203: selection of lines according to a pattern,
204: sorting of the input,
205: and encryption and decryption.
206: .SH
207: 6.3 Command separators; multitasking
208: .PP
209: Another feature provided by the \&shell is relatively straightforward.
210: Commands need not be on different lines; instead they may be separated
211: by semicolons:
212: .P1
213: ls; ed
214: .P2
215: will first list the contents of the current directory, then enter
216: the editor.
217: .PP
218: A related feature is more interesting.
219: If a command is followed
220: by ``\f3&\f1,'' the \&shell will not wait for the command to finish before
221: prompting again; instead, it is ready immediately
222: to accept a new command.
223: For example:
224: .bd 3
225: .P1
226: as source >output &
227: .P2
228: causes
229: .UL source
230: to be assembled, with diagnostic
231: output going to
232: .UL output ;
233: no matter how long the
234: assembly takes, the \&shell returns immediately.
235: When the \&shell does not wait for
236: the completion of a command,
237: the identification number of the
238: process running that command is printed.
239: This identification may be used to
240: wait for the completion of the command or to
241: terminate it.
242: The ``\f3&\f1'' may be used
243: several times in a line:
244: .P1
245: as source >output & ls >files &
246: .P2
247: does both the assembly and the listing in the background.
248: In these examples, an output file
249: other than the terminal was provided; if this had not been
250: done, the outputs of the various commands would have been
251: intermingled.
252: .PP
253: The \&shell also allows parentheses in the above operations.
254: For example:
255: .P1
256: (\|date; ls\|) >x &
257: .P2
258: writes the current date and time followed by
259: a list of the current directory onto the file
260: .UL x .
261: The \&shell also returns immediately for another request.
262: .SH 1
263: 6.4 The \&shell as a command; command files
264: .PP
265: The \&shell is itself a command, and may be called recursively.
266: Suppose file
267: .UL tryout
268: contains the lines:
269: .P1
270: as source
271: mv a.out testprog
272: testprog
273: .P2
274: The
275: .UL mv
276: command causes the file
277: .UL a.out
278: to be renamed
279: .UL testprog.
280: .UL \&a.out
281: is the (binary) output of the assembler, ready to be executed.
282: Thus if the three lines above were typed on the keyboard,
283: .UL source
284: would be assembled, the resulting program renamed
285: .UL testprog ,
286: and
287: .UL testprog
288: executed.
289: When the lines are in
290: .UL tryout ,
291: the command:
292: .P1
293: sh <tryout
294: .P2
295: would cause the \&shell
296: .UL sh
297: to execute the commands
298: sequentially.
299: .PP
300: The \&shell has further capabilities, including the
301: ability to substitute parameters
302: and
303: to construct argument lists from a specified
304: subset of the file names in a directory.
305: It also provides general conditional and looping constructions.
306: .SH 1
307: 6.5 Implementation of the \&shell
308: .PP
309: The outline of the operation of the \&shell can now be understood.
310: Most of the time, the \&shell
311: is waiting for the user to type a command.
312: When the
313: newline character ending the line
314: is typed, the \&shell's
315: .UL read
316: call returns.
317: The \&shell analyzes the command line, putting the
318: arguments in a form appropriate for
319: .UL execute .
320: Then
321: .UL fork
322: is called.
323: The child process, whose code
324: of course is still that of the \&shell, attempts
325: to perform an
326: .UL execute
327: with the appropriate arguments.
328: If successful, this will bring in and start execution of the program whose name
329: was given.
330: Meanwhile, the other process resulting from the
331: .UL fork ,
332: which is the
333: parent process,
334: .UL wait s
335: for the child process to die.
336: When this happens, the \&shell knows the command is finished, so
337: it types its prompt and reads the keyboard to obtain another
338: command.
339: .PP
340: Given this framework, the implementation of background processes
341: is trivial; whenever a command line contains ``\f3&\f1,''
342: the \&shell merely refrains from waiting for the process
343: that it created
344: to execute the command.
345: .PP
346: Happily, all of this mechanism meshes very nicely with
347: the notion of standard input and output files.
348: When a process is created by the
349: .UL fork
350: primitive, it
351: inherits not only the memory image of its parent
352: but also all the files currently open in its parent,
353: including those with file descriptors 0, 1, and 2.
354: The \&shell, of course, uses these files to read command
355: lines and to write its prompts and diagnostics, and in the ordinary case
356: its children\(emthe command programs\(eminherit them automatically.
357: When an argument with ``<'' or ``>'' is given, however, the
358: offspring process, just before it performs
359: .UL execute,
360: makes the standard I/O
361: file descriptor (0 or 1, respectively) refer to the named file.
362: This is easy
363: because, by agreement,
364: the smallest unused file descriptor is assigned
365: when a new file is
366: .UL open ed
367: (or
368: .UL create d);
369: it is only necessary to close file 0 (or 1)
370: and open the named file.
371: Because the process in which the command program runs simply terminates
372: when it is through, the association between a file
373: specified after ``<'' or ``>'' and file descriptor 0 or 1 is ended
374: automatically when the process dies.
375: Therefore
376: the \&shell need not know the actual names of the files
377: that are its own standard input and output, because it need
378: never reopen them.
379: .PP
380: Filters are straightforward extensions
381: of standard I/O redirection with pipes used
382: instead of files.
383: .PP
384: In ordinary circumstances, the main loop of the \&shell never
385: terminates.
386: (The main loop includes the
387: branch of the return from
388: .UL fork
389: belonging to the
390: parent process; that is, the branch that does a
391: .UL wait ,
392: then
393: reads another command line.)
394: The one thing that causes the \&shell to terminate is
395: discovering an end-of-file condition on its input file.
396: Thus, when the \&shell is executed as a command with
397: a given input file, as in:
398: .P1
399: sh <comfile
400: .P2
401: the commands in
402: .UL comfile
403: will be executed until
404: the end of
405: .UL comfile
406: is reached; then the instance of the \&shell
407: invoked by
408: .UL sh
409: will terminate.
410: Because this \&shell process
411: is the child of another instance of the \&shell, the
412: .UL wait
413: executed in the latter will return, and another
414: command may then be processed.
415: .SH
416: 6.6 Initialization
417: .PP
418: The instances of the \&shell to which users type
419: commands are themselves children of another process.
420: The last step in the initialization of
421: the system
422: is the creation of
423: a single process and the invocation (via
424: .UL execute )
425: of a program called
426: .UL init .
427: The role of
428: .UL init
429: is to create one process
430: for each terminal channel.
431: The various subinstances of
432: .UL init
433: open the appropriate terminals
434: for input and output
435: on files 0, 1, and 2,
436: waiting, if necessary, for carrier to be established on dial-up lines.
437: Then a message is typed out requesting that the user log in.
438: When the user types a name or other identification,
439: the appropriate instance of
440: .UL init
441: wakes up, receives the log-in
442: line, and reads a password file.
443: If the user's name is found, and if
444: he is able to supply the correct password,
445: .UL init
446: changes to the user's default current directory, sets
447: the process's user \*sID\*n to that of the person logging in, and performs
448: an
449: .UL execute
450: of the \&shell.
451: At this point, the \&shell is ready to receive commands
452: and the logging-in protocol is complete.
453: .PP
454: Meanwhile, the mainstream path of
455: .UL init
456: (the parent of all
457: the subinstances of itself that will later become \&shells)
458: does a
459: .UL wait .
460: If one of the child processes terminates, either
461: because a \&shell found an end of file or because a user
462: typed an incorrect name or password, this path of
463: .UL init
464: simply recreates the defunct process, which in turn reopens the appropriate
465: input and output files and types another log-in message.
466: Thus a user may log out simply by typing the end-of-file
467: sequence to the \&shell.
468: .SH
469: 6.7 Other programs as \&shell
470: .PP
471: The \&shell as described above is designed to allow users
472: full access to the facilities of the system, because it will
473: invoke the execution of any program
474: with appropriate protection mode.
475: Sometimes, however, a different interface to the system
476: is desirable, and this feature is easily arranged for.
477: .PP
478: Recall that after a user has successfully logged in by supplying
479: a name and password,
480: .UL init
481: ordinarily invokes the \&shell
482: to interpret command lines.
483: The user's entry
484: in the password file may contain the name
485: of a program to be invoked after log-in instead of the \&shell.
486: This program is free to interpret the user's messages
487: in any way it wishes.
488: .PP
489: For example, the password file entries
490: for users of a secretarial editing system
491: might
492: specify that the
493: editor
494: .UL ed
495: is to be used instead of the \&shell.
496: Thus when users of the editing system log in, they are inside the editor and
497: can begin work immediately; also, they can be prevented from
498: invoking
499: programs not intended for their use.
500: In practice, it has proved desirable to allow a temporary
501: escape from the editor
502: to execute the formatting program and other utilities.
503: .PP
504: Several of the games (e.g., chess, blackjack, 3D tic-tac-toe)
505: available on
506: the system
507: illustrate
508: a much more severely restricted environment.
509: For each of these, an entry exists
510: in the password file specifying that the appropriate game-playing
511: program is to be invoked instead of the \&shell.
512: People who log in as a player
513: of one of these games find themselves limited to the
514: game and unable to investigate the (presumably more interesting)
515: offerings of
516: the
517: .UX
518: system
519: as a whole.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.