An Operating Systems Vade Mecum

The command interpreter 239Sometimes the command interpreter is sophisticated enough to look for files and tocompare their creation dates in order to invoke steps in this chain only if they are needed.For example, the user might delete traffic.load because it uses up too much preciousdisk space. A later run traffic invocation will not invoke the Pascal compilerat all but will just repeat the final link step before executing the program. If the usermodifies traffic.pas (to add a feature, for example), then even thoughtraffic.load exists, run traffic will cause the command interpreter to repeatthe entire compilation and linking because the date on traffic.obj is earlier thantraffic.pas, so a change must have been made.Even the cleverest designers cannot predict all the shorthands that a particular usermight want. For example, some users wish to compile all their Pascal programs with aflag that disallows non-standard features in Pascal. A packaged automatic-chain facilitymight be unable to provide this slightly out-of-the-ordinary service. The mechanism cansometimes be stretched, for example, by letting the automatic chain itself take parameters,which are in turn converted to other parameters that affect the individual steps in thechain. This solution tends to increase the number of available options and leads to obscurity.An alternative solution is to let the user build an individual set of shorthands thataccomplish whatever is desired. Personalized shorthands constitute a fifth example ofthe User Principle. For example, a user might always want transfer to have the#fake flag set. This flag tells Transfer to delete files in a safe fashion by moving themto a different directory instead of actually destroying them. The user might invent a personalizedshorthand, delete, for this invocation. In the future, the command interpreterwill accept delete file to mean transfer #d #fake file. Personalizedshorthands can be established in the initialization file for the command interpreter.Automatic chaining can also be personalized. This act leads to a sixth example ofthe User Principle. A user who repeatedly needs a particular sequence of actions mightbuild a command script that contains the desired invocations. The command script canbe invoked instead of the individual commands. For example, to prepare a complex programthat contains several modules, the user might collect the commands necessary tocompile each of the modules and then link them all together. Command scripts are typicallystored in files. Some command interpreters can distinguish command scripts fromload images and interpret the first but invoke the second.Introduction of command scripts has had a strange effect on command languages;they have become more like programming languages. First, they have variables. Thesevariables are used to hold strings that can be pieced together to form commands or can beinspected to influence what is done next. Second, they have control structures. Commandscripts often need to repeat a set of operations once for each file in a set or untilsome condition is met. If an error occurs, the entire command script might need to terminate.The command script may take one action or another depending on some condition.Therefore, loop, exit, and conditional control constructs are common in commandscripts. At the least, they have a way to determine if a program ends in error and to takeappropriate action (such as termination) in that case. Third, they have procedures,insofar as they can invoke other command scripts and pass them parameters.To maintain a uniform interface, designers of command languages often allowthese same constructs to appear in normal commands presented directly to the commandinterpreter. It is unusual, but not unheard of, for a user to submit loop control constructsas part of ordinary interactive behavior. For example, a user may wish to make backup