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