| 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. |