An Operating Systems Vade Mecum

240 The User Interface Chapter 7copies of all files. The following is a loop command that might be provided by a commandinterpreter:foreach i in * dotransfer i i.bakendEach iteration of the loop sets the control variable i to the name of a different file. If thefiles have names Red, Green, and Blue, this loop command is equivalent totransfer Red Red.baktransfer Green Green.baktransfer Blue Blue.bakThe culmination of this tendency is to treat process control as purely a programminglanguageissue. One can use the same language for job control and for programming.This approach has some problems. First, interactive and non-interactive programmingare different enough so that the same constructs are unlikely to be properly tailored forboth. Second, non-interactive programs are read much more often than they are written,so a considerable percentage of the characters are present to make the program readable.Such a design is cumbersome when used interactively.An interesting programming-language approach has been taken by a few operatingsystems, notably ITS (Incompatible Timesharing System, for the PDP-10) at MassachusettsInstitute of Technology. The command interpreter and the program debuggerare the same. The debugger has the ability to invoke programs and to interrupt, examine,and modify them; all these facilities can be useful to a command interpreter.1.3 Interacting with programsOnce a process has been started, the command interpreter typically retires from the sceneand does not resume execution until the process that has been started is finished. At thatpoint, it might print completion statistics, such as how long the process ran and howmuch that execution cost or the fact that execution failed. If execution fails, the commandinterpreter may provide facilities for debugging, such as a main-store dump (typicallyuseful in batch mode) or an error message. Different error messages might indicatethat the process exceeded its allotted time, made an invalid service call, or tried to accessan address outside its space.In addition to starting processes and viewing their results, interactive users alsoneed to manipulate their programs while they are running. Remarkably often, users submitrequests that start programs that are not quite what the user intended. Perhaps someflags are accidentally omitted. Perhaps the compiler is invoked, and then the userremembers another change that should be made to the program. Perhaps the request isnot particularly important (for example, viewing the current load on the operating systemto find out why it seems slow today), and the user decides not to wait for it to complete.Interactive operating systems provide some form of ‘‘cancel’’ request that can be typedwhile programs are running. The effect is that the running process is terminated and thecommand interpreter resumes execution. The mechanism involved in terminating theprocess is often outside the control of the command interpreter; the device driver for theterminal notices the ‘‘cancel’’ character and forces the running process to stop. The