home *** CD-ROM | disk | FTP | other *** search
/ minnie.tuhs.org / unixen.tar / unixen / PDP-11 / Trees / V7 / usr / doc / cacm / p4 < prev    next >
Encoding:
Text File  |  1979-01-10  |  13.9 KB  |  518 lines

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