An Operating Systems Vade Mecum

The command interpreter 237When it starts a new process, it would tell the kernel not only which program to invokebut also what the global environment for that process should be.Local environment settings might have a similar syntax. Often, local settings areused to give extra information to the process or to select an optional behavior. Such settingsoften take the form of parameters, which are optional additions to the commandline that invokes the process. For example, we might have a general-purpose datatransferfacility called ‘‘Transfer.’’ The following are some different invocations ofTransfer with different parameters:1. transfer work.text work.save.text2. transfer #c work.text work.save.text3. transfer #r work.text work.save.text4. transfer #d work.text5. transfer #h #col=2 work.text /device/printerThe first call requests that a new file, work.save.text, be created with the contentscopied from work.text. Both files are given as parameters that provide necessaryinformation to Transfer. The second call is very similar, but an additional parameter,#c, is given. This parameter specifies the ‘‘careful’’ option, which tells Transfer not tocreate the new file if a file with that name already exists. Parameters that establishoptions are often called flags. The third call asks Transfer to rename the file instead ofcopying it. Perhaps the #c flag could be applied here, too. The fourth call does notrequest a transfer at all; it asks for the file work.text to be destroyed. The fifth callasks for the file to be copied to the printer, which is named by a full file name. The flagsask for a standard header to be printed along with the file (#h) and for 2-column outputto be used in order to save paper (#col=2).In each of these cases, the command interpreter might simply package all theparameters (flags as well as other parameters) and present them to Transfer as characterstrings without interpreting them at all. In that way, programs can define for themselveswhat a parameter should mean, and the command interpreter does not need to know anythingabout the multitude of flags that have meaning to different programs.Parameters can be presented to the program by several routes.If the command interpreter is a process, it might send the parameters in a messageto the new program. (We discuss messages in Chapter 9.)If the command interpreter is part of the kernel, the program can request parametersby service calls.The command interpreter can arrange for the new program to start with the parametersalready stored in its virtual space. (We discuss starting new processes inChapter 9.)1.2 The User PrincipleCommand interpreters are designed to make the most common operations as easy as possible.This goal is a human-engineering equivalent of the Cache Principle.