An Operating Systems Vade Mecum

244 The User Interface Chapter 7interpreter depends on whether a command or a parameter is to be completed. In theformer case, only legal commands are considered as acceptable completions. In the lattercase, only file names are allowed.If there is no legal way to complete the fragment or if there are two or more ways,the command interpreter signals an error (by ringing a bell). If the fragment can beunambiguously completed by a few more characters, but not to the very end, those fewcharacters are added. The user can type another key to have the command interpreter listall the possible completions of the current fragment.Subordinate command interpreters.If the operating system does nothave a foreground/background scheme, it may still be possible for a user to start severalunrelated activities. All that is needed is for one process to be able to start another andwait until it finishes. It is a common convention for interactive processes in Unix andTenex to accept a command that starts a new command interpreter. A user interactingwith process A who wishes to start process B might ask A to start up a new commandinterpreter. The new command interpreter may be asked to start B. Once B is done, asecond request may be given to the new command interpreter. When the user is ready toreturn to A, the new command interpreter is told to terminate, and A is active again.Figure 7.2 illustrates this situation. When the user first logs on, a command interpreter(number 1) starts. The user asks command interpreter 1 to start the mail program.The box around command interpreter 1 indicates that it is waiting for the mail program tofinish. One of the messages the user reads suggests that some recently created softwarehas a bug. To fix that bug, the user asks the mail program to start command interpreter 2.Until it finishes, the mail program is waiting, as indicated by the box around it.The user first tells command interpreter 2 to move to the appropriate workingdirectory. Then command interpreter 2 is asked to start a text editor so the user caninspect the program that has failed. The user finds the bug and modifies the file. It istime now to compile, link, and run the program. The user asks the editor for a new commandinterpreter (number 3). Command interpreter 3 is asked to run the compiler. Whenthe compiler finishes, the linker is run. The first situation shown in Figure 7.2 holdswhile the linker is running.Once the linker finishes, the user will try running the program. The bug is stillthere. To return to the editor, the user terminates command interpreter 3. After makingmore changes to the program, the user asks the editor for another command interpreter(number 4). The second situation in Figure 7.2 holds during the next compilation. If allgoes well, the user will terminate command interpreter 4, the editor, and command interpreter2, returning to the mail program. A response can be sent to the person who complainedabout the bug, and the user can proceed to read the rest of the mail.As you can see, it can be confusing to have several command interpreters at once.Each might have a different working directory. It is up to the user to remember the treeof invocations. Programs must be exited in reverse order to the order in which they areentered, and they are active only when they are at the leaf of the tree.Redirection of transput.Programmers would rather not tie a programinto any particular source for input or destination for output. However, these decisionsmust be bound at some point; the logical name used by the program must be associated