An Operating Systems Vade Mecum

246 The User Interface Chapter 7simulate data.one out.onesimulate data.two out.twosimulate data.three out.threeSimulate must discover the binding by examining its parameters.A very nice alternative is to let Simulate assume that ‘‘input’’ and ‘‘output’’ arelogical names that will be bound by the command interpreter. These two logical files willbe provided to every process that the command interpreter starts. If the user makes nospecial arrangements, the command interpreter can direct terminal input to the ‘‘input’’expected by the process and direct any data placed in the ‘‘output’’ file back to the terminal.If data are to come from or go to a file, that stipulation can be mentioned in the commandline, not as parameters passed to the process but as instructions to the commandinterpreter for establishing bindings; for example:simulate < data.one > out.onesimulate < data.two > out.twosimulate < data.three > out.threeIn this example, we have followed Unix syntax, in which < means ‘‘bind the input to thefile named next in the line’’ and > means ‘‘bind the output to the file named next in theline.’’ Different symbols are used so that the command interpreter can distinguishbetween file names and program names. The binding for either input, output, or bothcould be specified in the command. Unspecified bindings remain by default bound to theterminal.Redirection of transput can be carried one step further. The output of one processcan be directed into the input of a second process. For example, the result of the simulationcan be sent to a process that sorts the output before it is placed in a file. Our commandsmight take this form, again following Unix conventions:simulate < data.one | sort > out.onesimulate < data.two | sort > out.twosimulate < data.three | sort > out.threeThis ability to form ‘‘pipelines’’ colors the philosophy of building programs under Unix.Many programs are built to be simple elements of a longer pipeline, taking input, performingsome transformation (possibly quite simple), and producing output. We discussthe inter-process communication mechanisms used in Unix to build pipelines in Chapter9.Bit-mapped displays.In the earliest days of operating systems, most transputwas on punched paper tape or cards. Command interpreters understood certain combinationsof characters on tape or card to distinguish data from commands. The firstinteractive terminals were slow (about 10 characters per second) and noisy as they producedprinted output. Brevity of commands was more important than sophisticatedfeatures. Modern terminals are often quite fast (about 1000 characters per second) andquiet as they produce characters on a video screen. Many of the features mentioned sofar have been developed for this sort of terminal.