An Operating Systems Vade Mecum

238 The User Interface Chapter 7User PrincipleOperations that are performed frequentlyshould be especially easy to invoke.The designers of the command interpreter should try to predict and simplify common patternsof invocation.The first example of the User Principle is the use of default settings. Programs areoften written so that in the absence of special instructions, they do what the designersassume is the most natural, most frequently desired action. For example, most compilerson interactive operating systems will not create a listing file unless asked to because mostusers won’t want it. However, creating a listing file is an option that can be added to theenvironment of the compiler process (typically through a flag). Another example is thatthe output of many programs in an interactive operating system is to the user’s terminal.A change in the environment can redirect the output to, perhaps, a file or a printer.A second example of the User Principle is the use of a simple built-in shorthandfor a more complex operation. Some command interpreters have a list of standard commandsthat invoke optional utilities that have names unrelated to the command. Forexample, edit may be used to invoke the editor utility, whose real name might besomething complex like editor.utility. Delete may be used to delete a file;the actual program invoked may be the Transfer program shown earlier, which can do farmore than just delete files. The command interpreter forms the correct parameters forTransfer when given the command delete. The list command might invoke thesame program Transfer with different parameters. This use of built-in shorthands freesthe casual user from remembering the many flags available for programs like Transfer.A third example of the User Principle is the initialization file. Heavily used programstend to acquire a host of options, most of which are irrelevant to most users. Theoccasional user who wants to set an option may wish to do so every time the program isinvoked. For example, many users will be happy with the normal prompt given by thecommand interpreter. Others will want a customized prompt. Most users may not want afeature in the text editor that automatically hyphenates text at the end of a line. A fewwill want it every time they use the editor. Such customization may be embedded in afile as a list of initialization settings. The name of the file is related to the name of theprogram. For example, initialization instructions for the text editor may be stored in afile called editor.init. Whenever the text editor is invoked, it first looks for such afile to initialize its options.A fourth example of the User Principle is automatic chaining, which invokes afrequently needed sequence of programs with a single command. In many installations,such as university computing centers, users spend much of their time preparing programs.Some command interpreters provide a shorthand that combines compilation, linking,and execution of a program in one command. For example, a traffic simulation programwritten in Pascal might be compiled and executed by the command runtraffic. The command interpreter would see that there is a file in the current workingdirectory called, for example, traffic.pas, decide that the file is a Pascal sourceprogram, invoke the Pascal compiler in an environment that has the compiler place theoutput in traffic.obj, link in the Pascal run-time support routines to buildtraffic.load, and then invoke this last file as a process.