Chapter 8, Command Interpreters

Lecture notes for 22C:116 Introduction to System Software, by Douglas W. Jones, University of Iowa Department of Computer Science

Preface to Part II

The following chapters introduce concepts which are important in a single user operating system. This begins with a discussion of a command language which is sufficient to control the operation of the programs described in the previous section; this plus the chapter which follows on sequential input-output provide a sufficient basis for writing an operating system which is typical of first generation computers ranging from the vacuum tube machines of the 1950s to the Minicomputers of the 1960s or the early personal computers of the 1970s.

The result is, just barely, a complete system, but such a system would hardly impress an experienced user of more advanced operating systems! The additional chapters that follow in this section are devoted to techniques for improving input-output efficiency and supporting random access devices. Finally, file systems are discussed, bringing the example up to the state of the full-featured single user systems that ran on the minicomputers of the 1970s and the personal computers of the 1980s.

The demand for dynamic resource allocation posed by file systems or window managers, and the concurrent processing involved with high performance input-output devices drive the transition to the final section of this text where the focus shifts to multi-user systems and resource sharing.

A Simple Operating System

Since the 1960's, customers have demanded a minimal suite of system software when they buy even the smallest computer systems. The bare minimum consists of a text editor, an assembler, a linker, a loader, a set of subroutines for doing input-output, and a command language for directing the operation of the various programs. Although these software components are sometimes lumped together as the operating system, it is generally useful to differentiate between the system support utilities such as editors and language processors, on the one hand, and the run-time services offered by the operating system and command language on the other hand. The former are used in preparing a program to run, while the latter are used to run programs once they have been prepared. Throughout this text, the term operating system will be reserved to refer to the latter.

The minimal operating system to be discussed here is typical of the single-user systems found on most early machines. These include the mainframes of the 1950's, the minicomputers of the 1960's, and the microcomputers of the 1970's. Few general purpose computers in common use today have such primitive operating systems, but most of today's operating systems can be viewed as simple extensions to such a system.

The term general purpose is, of course, essential to the above paragraph. Special purpose computer systems are frequently sold with no operating system at all. Embedded computer systems, those that become part of some large product, whether a home appliance, an airplane or a laboratory instrument frequently execute fixed programs where the line between system and application is completely blurred. The programs for such systems are frequently developed on general purpose computers and burned into read-only memory as part of the manufacturing process.

Although the particular set of peripheral devices attached to the computer is not of critical importance in this discussion, it is useful to consider a system with the following peripherals: A keyboard for user input, a display screen for output, a printer, and a number of sequential files. On a modern system, these sequential files would usually be stored on one or more disk drives, but disk drives are complicated. In order to build a minimal system very quickly, we are better off talking of extremely simple I/O devices like the cassette tapes that were widely used with the first generation of personal computers in the 1970's. Figure 8.1 illustrates such a system.

 __________                     --| tape 1 |
|          |                   |  |________|
| display  |      __________   |   ________
|  screen  |-----|          |--   | tape 2 |
|__________|     | computer |-----|________|
               --|          |--
 __________   |  |__________|  |   _________ 
| keyboard |--                  --| printer |
|__________|                      |_________|

Figure 8.1. A dismayingly simple computer system.

In the early 1950s, such a system would have cost millions and occupied a large machine room, while by the mid 1980s, such a system would only cost a few hundred dollars. The operating system requirements for such a simple computer system do not depend on the tape technology being used, and they do not depend on whether the computer has a microprocessor or vacuum tubes in its heart.

The tape drives used by computers of the 1950s and 1960s used half-inch wide magnetic tape, wound on reels that were up to a foot in diameter. The drives themselves were the size of a refrigerator, and large computer centers frequently had tape drives lined up along an entire wall of the center, dwarfing the CPU. It is no wonder that cartoonists of the 1950's and 1960's frequently focused on these gigantic tape drives as a visual symbol of computers and computer technology.

System Structure

The run-time system services provided by a single-user operating system for a machine such as that illustrated in Figure 8.1 would typically allow for the following operations: input from any device other than the display screen, output to any device other than the keyboard, rewinding any tape drive, and loading a program from any tape drive. These services can be packaged in any of a number of ways, but since the loader service itself requires use of the input service, it is reasonable to think in terms of the hierarchic design shown in Figure 8.2.

|                                         |
|           the command language          |
|                interpreter              |
|                                         |
|          _______\calls/_______          |
|         |                     |         |
|         |     application     |         |
|         |      programs       |         |
|         |                     |         |
|_\calls/_|_\calls/_            |         |
|                   |           |         |
|      loader       |           |         |
|                   |           |         |
|                                         |
|           input-output library          |
Figure 8.2. A hierarchic design for a simple operating system.
The hierarchy shown in Figure 8.2 can be thought of in terms of subroutine call relationships, with the calling system component on top and the called component on the bottom. So, the input-output library provides services called by all other parts of the system, and the command language interpreter calls input-output library services to read the command language, it calls the loader to load the programs it is commanded to load, and it then calls the programs themselves. Application programs call input-output library routines, and if they include overlays, they also call the loader.

When a computer system has no protection mechanisms, that is, mechanisms to prevent application code from corrupting the operating system, calls from application code to system services and calls from the command language interpreter to user code are all generally done using the same subroutine call instructions that one part of an appliction might use to call another part of the same application.

On large computers with protection mechanisms, normal subroutine calls are only used to call procedures or functions within the same protection domain, while calls that cross domain boundaries frequently use entirely different mechanisms. This change of mechanism involves no change in the user's intent, but is only required in order to prevent unauthorized accesses from either calling or called routine to code or data belonging to the other. Because of this, we will emphatically avoid mention of protection and treat all system services as if they were simple subroutines that can be called by the same mechanisms used to call parts of user programs.

A Set of Input/Output System Services

In many primitive systems, a different subroutine was provided for each system service. As a result, a user wishing to change a program to read from tape drive A to tape drive B would be forced to rewrite the program. In a remarkable number of cases, different devices actually used different character sets, so it was necessary to change the code that processed the input or generated the output when the change was made from outputting to the printer instead of outputting to the display screen or when a change was made from keyboard input to input from tape. Even in the mid 1950's, these extreme cases were the subject of ridicule, and programmers strove to create uniform interface standards.

The FORTRAN language, developed in the mid 1950's by John Baccus at IBM, provides for a uniform input-output interface by addressing all input-output operations to abstract input-output units. All a programmer needs to do in order to change the unit being operated on is change the unit number. On a very crude system, unit 1 might be the keyboard, unit 2 might be the display, unit 3 might be the printer, and units 4 and up might be tape drives.

Numerical unit numbers are an improvement, but named devices are even more convenient. Systems designed since the mid 1960's have generally allowed to symbolically named devices, and as file systems became common, symbolic file names. This requires that the system include a symbol table, the device table, and on later systems, the directory of the file system, which is used to translate file and device names to the device codes used internally.

If cost was no object, we might be tempted to invent a system input-output service along the lines of put(d,c) where d is a symbolic device name, and c is a character to be output to that device. The problem with this idea is that it suggests that we have to look up the device by its symbolic name once for each character output to that device, and we do not generally want to pay the price of so many lookup operations.

In order to avoid excessive device-table lookup operations, we typically introduce a new operation, open that takes a symbolic file or device name and returns a descriptor for that file or device. In crude systems, the descriptor is nothing more than an old FORTRAN-style unit number, but in an abstract sense, an I/O descriptor is always the handle on an object that represents an I/O device that is capable of performing the basic I/O operations, usually given names such as read, write and rewind (the classic FORTRAN names) or put, get and seek (in the C tradition).

The opened file descriptor can be described as an abstract data type, as was done in Figures 3.2 through 3.4 for symbol tables. This is partially shown in Figure 8.3.

Sets needed

S -- the set of symbolic file names
F -- the set of file descriptors
C -- the set of characters

Functions on the sets

open: S --> F
rewind: F --> F
read: F --> F x C
write: F x C --> F

Informal descriptions

open(f,s) or f = open(s)
sets f to refer to the device with the symbolic name s; usually, this involves an implicit rewind.

rewind(f) or f.rewind
positions f at the start of file.

read(f,c) or c =
reads the character c from f.

write(f,c) or f.write(c)
writes the character c to f.

Figure 8.3. The file variable abstract data type.

In Figure 8.3, two different concrete notations are shown for the calls to the read, write and rewind operations. The lefthand notation is a purely procedural notation, where read, write and rewind operate through side effects on their parameters; the righthand notation is an object-oriented notation where the operations are the methods of the class, and a device descriptor is a handle for objects in this class. Aside from the question of programming language syntax, these views are equivalent!

The input-output operations suggested in Figure 8.3 are sufficient for most purposes, but they are hardly convenient! If these are the only available services, programmers would be required to do all input-output one character at a time, and this poses both conceptual and practical problems. Most systems therefore provide additional services such as those suggested in Figure 8.4.

readblock(f,b,i) or f.readblock( b, i )
reads a block of i bytes from f to buffer b.

writeblock(f,b,i) or f.writeblock( b, i )
writes a block of i bytes to f from buffer b.

readline(f,b,i) or f.readline( b, i )
read a line of up to i bytes from f to buffer b. if less than i bytes were read, an line terminator character will follow the last character of input.

writeline(f,b,i) or f.writeline( b, i )
write a line of up to i bytes to f from buffer b. if the buffer contains a line terminator character, the write will stop before writing i characters, and the last character output will always be a line terminator.

Figure 8.4. Additional input-output routines.

In an object-oriented world, we can view the additional services shown in Figure 8.4 as being provided by a class-extension to the basic set of services, but this presumes that all devices support the basic character sequential services as primitives, and this is not true! Devices such as the keyboard do indeed support character sequential input, and low-end printers support character sequential output. Most tape formats, however, are implemented as block sequential formats, with hardware interfaces that directly support operations analogous to readblock and writeblock. On these, the character oriented services would be logically an extension of the block oriented services!

Even when our underlying devices are character sequential, it is frequently a good idea to provide block-oriented I/O services as primitives on high performance devices. The reason for this is twofold. First, the overhead of one subroutine call per character being output can be significant, and second, some devices only perform well if there is a guarantee that data will arrive at a uniform rate. For example, consider a high-speed tape reader. To read one character, the device must start the tape moving, read, and then stop the tape. To read a block of characters, the tape can be started and left moving for the entire length of the block. As a result, using character oriented I/O to read a block of 100 characters might end up starting and stopping the tape 100 times, while using a block-oriented approach would only have one start and one stop. Mechanical start and stop operations can be very slow compared to the electronic operations of actually reading or writing a byte of data!

Note that the typical input-output primitives presented in Figures 8.3 and 8.4 are significantly different from the primitives of high level languages such as Pascal or C, in that no provisions are made for data format conversions. Most programming languages include an intermediate software layer between the operating system's input-output routines and the user for format conversion between textual representations of values and their internal representations. Thus, FORTRAN has its FORMAT statement, C has fprintf() and fscanf(), and object oriented languages tend to include standard methods for each predefined class to perform such conversoions. However it is presented to users, format conversion layer of a language can be dismayingly complicated.

Protection mechanisms can complicate the way in which a user views a file variable, since the contents of this variable are, in a sense, the private property of the file system. In an unprotected environment, file variables can be records (or pointers to records) containing whatever information is necessary to access a particular device. In a protected environment, the system must be able to guarantee that no user can misuse the information in the file variable, even if the user is working in a language like C or assembly language, where the language does not enforce type integrety.

The protection mechanisms of operating systems frequently protect the open file variables or file descriptors by removing this information from the address space of the user program. Instead of giving the user a pointer to the data structure describing an open file, the user is given a small that is the index into a small array of open file descriptions, where there is one array entry per file that user has open. This exactly matches the old Fortran model, with open files described by unit numbers, and it is, in fact, the model that is used in UNIX.

On some systems, notably OS on the IBM 360/370/390, slots in this table have symbolic names; typical (and widely used) names are SYSIN, SYSPRINT, and SYSPUNCH. Since the table for any user is small, the cost of a linear search for a table entry is small enough that the open file table can be searched each time the user manipulates a file.

Some systems provide a radically different set of primitives; an extreme alternative is to have a single input-output system service which accepts a file control block as a parameter. This block is a record listing such things as the buffer address and size, the direction of the transfer, the type of the transfer (line or block), whether the file should be rewound before the transfer, the name of the file to be used, and space for the system to fill in additional information. Typically, on the first call to this general input-output routine, the system looks up the file name in the directory and the system space in the block is initialized to contain the information which would otherwise reside in an opened file descriptor. All subsequent calls will be fast because they do not need to look up the file name. The risk in such systems is that the user might accidentally corrupt some of the system information in the file control block.

Loader System Services

The smallest of systems sometimes offer only an absolute (non-relocating) loader, thus forcing all application code to be written with knowledge of where in memory it will eventually be loaded. Since relocating loaders are only slightly more complex than absolute loaders, most systems provide a relocating loader. Some larger systems provide, as a system service, a linking loader, but when linking loaders are provided, they are frequently not system services, but must first be loaded themselves before they are run.

Typical loaders must be passed the name of the file to be loaded or they must be passed a file variable which has been opened to that file. If the loader can handle relocation, it must be passed the initial relocation base, and it will probably return the address of the highest location used. The loader must return the starting address of the loaded program if it does not transfer control to it. For the example system, the loader system service described in Figure 8.5 will be assumed.

load from file variable f using relocation base b; return s, the starting address. If there is no starting address, s=-1.

Figure 8.5. A loader system service.

The loader service described in Figure 8.5 relies on its caller to allocate memory for the loaded program, and it relies on its caller to handle any transfer of control to the loaded program. Typically, there will be some system wide convention about how the caller can transfer control to the program; a typical convention would require that the caller perform a procedure call to the program, thus allowing the loaded program to return to the caller when it is done.

In systems where the loader automatically transfers control to the loaded program, the system must include a facility allowing the user to transfer control back to the caller when it is done. Thus, on such systems, there is frequently an end or exit system service which a program can use to tell the system that it is done. Such services are especially important on systems which do not have much memory, since on such a system, it is common for the loader to load the new program directly into the memory which had been used by the caller, thus requiring the caller to be re-loaded when the loaded program ends.

Small operating systems may offer no storage management services at all, thus requiring that user programs include any code needed for storage management. A common storage management discipline on such a system establishes all of memory as a stack; whenever a program wants to load another program, it loads it immediately beyond itself in memory, thus effectively pushing one program on the stack. If procedure calls are done using a stack, this may require a second stack, as is shown in the map of the memory usage on such a small system given in Figure 8.6.

| code for |   command   |  user   |  user   |//////////////| procedure |
|  system  |  language   | program | program |//// free ////|  calling  |
| services | interpreter |    1    |    2    |//////////////|   stack   |

Figure 8.6. Map of the memory use in a typical small system.

The widely used MS/DOS system of the early 1980's followed a model very close to that shown in Figure 8.6.

Figure 8.6 shows the state of the system while user program 2 is running, where user program 2 was loaded and then called by user program 1, and user program 1 was loaded and called by the command language interpreter. In this kind of simple environment, it is useful for a program to be able to find the highest address it occupies so that it can tell where memory is available to load any programs it needs. To simplify this, we will assume that the linker implicitly defines the relocatable symbol "codetop" as the address beyond the end of each loadable file.

On larger operating systems, services are usually provided for allocating and deallocating memory, and the loader frequently makes direct use of these services to obtain memory for the relocatable parts of loaded programs. The form that these services take is frequently strongly dependent on the structure of the system hardware; thus, these services are frequently quite different from the storage management services offered to user programs in high level languages (eg. Pascal new and dispose, C malloc and free, or C++ and Java object creation).

The use of loader system services by one user program which loads and calls another is very similar to the use of the same services when the main segment of a user program calls a procedure in one of its overlays. As a result, the explicit use of loader system services is sometimes described as a form of overlay management. An alternate view of this is that a user program which loads another and then calls it is making use of run-time linkage or dynamic binding, as opposed to pre-run-time linkage such as typically done with a linkage editor.

Communication Between Programs

When the command language interpreter loads a user program, or when one user program loads another, a new problem arises: How can the newly loaded program be told why it was loaded and what it is to do? Very simple systems provide little in the way of a solution to this problem, so a program which has been loaded must open a communications channel with the user and ask why it was run and what it is to do. This makes it very hard to write general utility programs which can be run interactively by a user one time, and run automatically by another program at a different time.

Since the 1960's, a common solution to this problem has been to introduce the concept of parameters to an executable program. This solution implicitly underlies the design of the Pascal language, where each program has a heading that lists, as parameters, the files 'input', 'output', and optionally others. Thus, it is reasonable to think of a Pascal compiler translating the heading of a program as illustrated in Figure 8.7.

Original Pascal program heading:
program p( input, output, listing );
Equivalent C function heading:
#include <stdio.h>
void p( FILE *input, FILE *output, FILE *listing )

Figure 8.7. Program parameters.

This approach allows the user of a program to set up the files used by that program before running it, whether that user is another program or a person running the program via the command language interpreter.

Another approach to solving this problem is sometimes used on systems which maintain a table of opened files on behalf of each user. For example, under the classic OS operating system on the IBM 360/370/390 series of machines, where the opened file table has symbolic names for its slots, the slots named SYSIN and SYSPRINT are usually used for standard input and output by most programs, so a program which runs another program can first reset these files appropriately in order to change where input-output is directed. Similarly, the files addressed by the integer unit numbers 0, 1 and 2 under UNIX are used for standard input, standard output, and error messages, respectively. A program which wishes to run another program on particular input-output files can first close these units and then re-open them on the new set of files.

Although most Pascal systems only allow files as program parameters, there is nothing to prevent a language implementor from allowing arbitrary parameter types on a program. On systems where only files may be passed as program parameters, or where files are referenced through a system managed table of opened files, it is common to provide special mechanisms for communicating other kinds of information to programs. For example, some systems maintain a table of named variables, with special system services to set the value of a variable or to retrieve it.

The UNIX model for communication with programs, a model that is fairly well incorporated into the standards for C and C++ includes two independent classes of program parameters. The first is a list of open files, indexed by file number, where file 0 is standard input, file 1 is standard output, and file 2 is standard error. The second is an array of textual parameters, operating as shown in Figure 8.8.

An example C program
int main( int argc, char * argv[] )
    int i;
    printf( "argc = %d\n", argc );
    for (i = 0; i < argc; i++)
        printf( "argv[%d] = %s\n", i, argv[i] );
    return 0;
The command line sed to execute this program
a.out runs the program
The output when the program is run
argc = 4
argv[0] = a.out
argv[1] = runs
argv[2] = the
argv[3] = program

Figure 8.8. Textual parameters to a C program

The example program in Figure 8.8 simply tests the passing of textual parameters to the main program by printing the parameter count and the parameters. The parameter count is passed as the first parameter, conventionally called argc, while the second parameter is an array of strings, conventionally called argv (the argument vector). The convention is that the first parameter, argv[0], is always the name of the program, and as a result, argc always seems to be one more than the number of parameters.

The example in Figure 8.8 also illustrates a feature of the C and UNIX environments that many programmers find to be very obscure. The main program in C is not a procedure, but rather, it is an integer function. By convention, returning zero indicates a normal exit, while a nonzero value such as -1 indicates an error. C (or C++) programs may also terminate by calling exit(v) to return the value v without executing all the way to the end of the main program; this is like using the return command to escape prematurely from a function.

A Command Language

A library of system services which allows any program to perform input-output operations and to load and run any other is a sufficient foundation for developing applications programs, but if that was the only componet of the operating system, we would have no way to start the computer running some application or to take control when that application terminates. In sum, we need a main program that can call the loader to load and run our application programs!

The primary function of this main program is to control the sequence of execution from one application to the next and to pass any parameters needed by the applications. To support this function, we invent command languages, and we refer to the main program as a command language interpreter. Sometimes, because the command language interpreter can be seen as a wrapper around applications, we refer to it as a shell. This terminology grew out of UNIX usage. In the older world of punched cards, each deck of cards fed into a computer was frequently described as a job, and the term job control language or JCL is widely used to describe command languages that date back to the punched card era.

Textual command languages such as JCL for the IBM 360/370/390, the various UNIX shell languages, or the MS-DOS command language can be contrasted with the Window Icon Mouse Pointer or WIMP command languages supported by Microsoft Windows, Apple's MacOS and the X window manager under UNIX. These windowing environments may not seem to support a language, but in fact, the replacement of text by mouse clicks does not change the status of the language as a language.

When we start a computer system, the bootstrap loader must load the command interpreter, the loader and the input-output library, and then it must start the command interpreter running. The command interpreter then begins reading commands in its command language and executing them. A simple command language interpreter for a trivial textual command language might have the form illustrated in Figure 8.9.

program command_interpreter;

var in, load: filevariable;
    filename: string;
    start: address;

     open( in, 'keyboard' );
     while true do begin
          readline( in, filename, stringlength );
          open( load, s );
          loader( load, codetop, start );
          call( start );

Figure 8.9. A simple command language interpreter.

The command language interpreter shown in Figure 8.9 reads commands from the keyboard, where each line of input is interpreted as the name of a file, or on a very simple system, the name of a device from which a program is to be loaded and then run. We assume a loader that takes, as parameters, the file to be loaded, the first address available for loading, and the variable to hold the starting address of the program, and then, we assume that the built-in function call() can be used to call the function that was just loaded.

Note that the interpreter given in Figure 8.0 processes a very simple command language. Each line of input from the keyboard holds the name of a file or device from which a program should be loaded and run. In fact, this is the core of all the UNIX shell languages, but as with all practical command languages, the UNIX shells allow much more.

A more useful command language should allow communication with the loaded programs using one of the communication techniques discussed in the previous section. Assuming that each program is written to accept exactly 3 files as program parameters, with no other program parameters, as as shown in Figure 8.7, the control language might have the form of a sequence of procedure calls, each taking 3 parameters, which are the names of files or, in a very crude system, the names of tape drives, where the special parameter "*" indicates that the called program is to use the same file or drive as was being used by the command language interpreter itself for the same purpose.

Figure 8.10 illustrates the use of this improved command language to assemble two files, link them, and run the result.

assemble( A, temp1, *)  -- 1, source on A, object to temp1
assemble( B, temp2, *)  -- 2, source on B, object to temp2
link( *, temp3, *)      -- 3, link to temp3
use "temp1"             -- 4, input to linker
use "temp2"             -- 5, input to linker
end                     -- 6, input to linker
temp3( *, *, *)         -- 7, run the linker's output

Figure 8.10. An illustration of the use of a command language.

In Figure 8.10, the first two lines run the program found on the file or tape drive called assemble. Assuming that this is an assembler, it will take the source programs on files (or tape drives) A and B and produce object code on files (or tapes) temp1 and temp2.

The third line in Figure 8.10 runs a program from a file called link. If this is the linker, we expect it to read a list of files to be linked from its input file; in this case, the input is from the same file being used for input to the command language interpreter, so it reads the lines that follow, lines 4, 5 and 6. The output of the linker is directed to temp3. The linker we are using in this example reads a list of linker commands its input file; in this case, two use commands indicating the names of files to be linked, and an end command indicating that there are no more files to be linked.

The final line in Figure 8.10 goes to the command interpreter, telling it to run the program that the linker wrote to temp3. This is run with all input and output directed to the same files used by the command language interpreter.

Looking over Figure 8.10, it is easy to see that we never need more than 3 tape transports, but if we have no concept of files more complex than "the cassette tape loaded on some transport", we'd have to stop and change tapes at almost every step shown in the figure. On the other hand, if we have 5 tape transports named assemble, link, temp1, temp2, and temp3, we would be able to do very complex program development. This is why those old computer centers that used half-inch magnetic tape for everything frequently had a long wall of tape transports.

While a file system that allows multiple named files to be stored on one device makes everything more convenient, the file system itself is not usually part of the command language, but rather, is part of the underlying library of input-output services, available for use equally by the user program and the command language interpreter. Even if we ignore this, the command language interpreter itself is usually far more complex than that suggested above. The UNIX shell languages are quite typical; while they differ in many details, all of the common UNIX shells support supersets of something like the following syntax:

<command> ::= <filename> { <parameter> } [ < <infile> ] [ > <outfile> ]
The full syntax of a Unix shell command is complex, so we will break it down in the following sections.

<command> ::= <filename>
Normally, if you type a file name in on a line by itself, the shell will simply execute the code in that file, letting that program read input from the same file the shell was reading from and letting the program write output to the same file the shell was writing its output to.

<command> ::= <filename> <parameter1> <parameter2>
If additional lexemes appear following the file name (identifiers, quoted character strings), they are passed as textual parameters to the program being executed.

<command> ::= <filename> < <infile>
If the command includes a < symbol, the text following this is interpreted as a file name, and that file is opened as the input file for the program being loaded and run.

<command> ::= <filename> > <infile>
If the command includes a > symbol, the text following this is interpreted as a file name, and that file is opened as the output file for the program being loaded and run.

<command> ::= <command> ; <command>
A sequence of commands may be given on one line, separated by semicolons. When this is done, they are executed left to right, in sequence.

<command> ::= <command> && <command>
When a double ampersand separates the commands on a line, the program on the left is loaded and run first, and only if its return value is zero is the program on the right run. Recall that, by UNIX convention, programs return zero to indicate that execution was successful. they return nonzero to indicate that an error occurred.

<command> ::= <command> || <command>
When a double vertical bar separates the commands on a line, the program on the left is loaded and run first, and only if its return value is not zero is the program on the right run. Recall that, by UNIX convention, programs return nonzero values to indicate errors.

In addition, the UNIX loader always inspects the first two bytes of the file being loaded. If this byte is a "magic number" indicating that the file contains executable machine code, the loader operates normally, loading that file and then calling the main program of the file that was loaded. If, on the other hand, the file begins #sh or #csh (or, for that matter, #shellname, where shellname is the name of any particular command language interpreter), the loader will execute that command language interpreter to act on the remainder of the file.

In effect, files starting with # are the names of command language files that are executed by the indicated shell. In UNIX, such files are referred to as shell scripts; the corresponding Microsoft terminology is a .BAT file. In many ways, these serve as shell macros, and all of the concepts of macro expansion apply. Furthermore, because all common shells contain conditional mechanisms (at the very least, they contain the && and || mechanisms), we have the complete flexibility of conditional and macro assembly!

Before the command language interpreter acts on a line, it performs some simple macro substitution. All common UNIX shells use the following notation for this substitution:

substitute the indicated parameter; script one two three will, for example, replace $1 with one, $2 with two and $3 with three, assuming that script is the name of a shell script.

In sum, all of the UNIX shells incorporate conditional and macro processors, and in fact, all of the UNIX shells are sufficiently general that the shell languages are, in fact, fully sufficient to be used to write any computer program without resorting to executing any machine code other than the command language interpreter. Unfortunately, the different shells are incompatable with each other for all but the most elementary purposes, so it is necessary to ask a UNIX shell programmer whether he knows sh (the original UNIX shell, known as the Bourne shell, after its author), csh (the C shell), bash (the "Bourne again" shell) or some other.

The reason that there are so many UNIX shells is that there is nothing special about the UNIX shell. Several are distributed with each UNIX system, but programmers are entirely free to write their own if they don't like the shells that come with UNIX. This is quite different from, for example, the old IBM JCL command language, where there is only one JCL interpreter that is a privileged part of the operating system that cannot be easily separated from the system and replaced by user code.

The job control language of the classic OS operating system on the IBM 360/370/390 series of computers is worth illustrating, albeit breifly. A JCL program consists of a series of job steps, where each job step may consists of several lines describing the loading and execution of one program. A job step consists of a number of "DD" (data definition) lines which describe the files which a program is to use, followed by an "EXEC" line which specifies the program which is to run using those files. The reason that IBM JCL takes so much more text than the UNIX shell language is that the file descriptions needed to open a file under the OS operating system are very complex, including not only the file name, but the block size to be used for reading or writingwith the file, the logical record size of the file, and many other parameters.


The reader should be familiar with the following terms after reading this section:

run-time services               storage management
command languages               dynamic linkage
supervisor call instructions    run-time binding
opened file descriptors         program parameters
file variables                  command language procedures
input-output primitives         UNIX shell
file control blocks             IBM job control language
In addition, the reader should be familiar with the following system services of the example operating system:
open                            writeblock
rewind                          readline
read                            writeline
write                           loader
readblock                       codetop


  1. Using only the basic input-output services suggested in Figure 8.3, propose implementations of:

    a) "readblock", as defined in Figure 8.4.

    b) "writeblock", as defined in Figure 8.4.

    c) "readline", as defined in Figure 8.4.

    d) "writeline", as defined in Figure 8.4.

  2. Propose implementations of the higher level output primitives documented in Figure 8.4 in terms of those defined in Figure 8.3. These implementations would be appropriate if the underlying device is performs character sequential input-output. Present your answer as pseudocode.
  3. Propose implementations of the the character sequential read routine in figure 8.3 in terms of the block sequential readblock routine in figure 8.4. To do this, you will have to assume that each file variable has several components, for example, the block size to use for this file, the current position in the block, and perhaps the current block itself. Present your answer as pseudocode.

  4. In the chapter on linkers, it was mentioned that calls from the main program to procedures in an overlay were replaced with calls to a load-on-call stub which loads that overlay and then passes control to the desired procedure. Consider a parameterless procedure "p" which has been link edited into an overlay stored in file "pfile". Write code for a load-on-call stub for "p" using the loader service suggested in Figure 8.5. The code shown in Figure 8.9 may provide a useful illustration of how to do some of the operations needed for this.

  5. On a system with loader services such as are suggested in Figure 8.5, where memory is organized as suggested in Figure 8.6, how would you detect that the system is out of memory, and when would you make checks for this situation? Assume that the stack has one entry pushed on it each time a procedure or function is called, and that this entry holds all local variables and any other memory needed by that procedure.

  6. In some systems, user programs can call the command language interpreter as a function, passing it an open file from which commands are to be interpreted, and user programs can call the a command-line interpreter, which takes just one command line as a parameter, plus the a list of current parameters that may need substitution, and interprets just that line..

    a) Redraw Figure 8.2 to take into account both of these. You should show the fact that the command language interpreter and the user may both call the command line interpreter, the fact that the command line interpreter is the one that calls user programs, and the fact that the user may also call the command language interpreter. Don't expect a pretty result!

    b) Write code, in the style of Figure 8.9 (but in the language of your choice) to implement the command line interpreter.

    c) Write code, in the style of Figure 8.9 and using your answer to part b to implement the command language interpreter library routine.

    d) Write code, in the style of Figure 8.9 and using your answer to parts b and c to implement an appropriate main program so that, when the system first begins operation, the command language interpreter begins reading commands from the keyboard.


The subjects discussed in this chapter are covered to a remarkably uneven extent in the literature. Many authors seem to consider system command languages to vary so extremely that there is little that unifies the command languages of different systems, while others consider the subject to be so elementary that it does not require discussion. The discussion of command languages in Section 4.4 of

The Logical Design of Operating Systems by A. C. Shaw (Prentice Hall, 1974).
may be helpful. Section 7.4 of
Operating System Elements, A User Perspective by P. Calingaert (Prentice Hall, 1982).
is also a reasonable source.

For a discussion of the classical IBM 360/370/390 job control language, see

Operating Systems by H. Lorin and H. M. Deitel (Addison Wesley, 1981).
This discussion starts in Section 2.3.2, and continues in Section 6.4.1. Chapter 7 contains a discussion of system services, although the term is used slightly differently than it is here; this chapter includes a discussion of the command language interpreter.

For information on UNIX, see

Understanding UNIX, a Conceptual Guide by J. R. Groff and P. N. Weinberg (Que, 1983)
Chapter 5, contains an extensive discussion of the UNIX shell. The official description of the UNIX shell is included in section sh(1) of the
UNIX Programmers' Manual, Vol. I (Holt, Rinehart and Winston, 1983).
Sections open(2), read(2), write(2), and lseek(2) provided much of the inspiration for the basic input-output services discussed in this chapter. Section exec(2) documents the way in which the UNIX loader is called; this was not used as a pattern for the loader service described here, but is an interesting contrast.

Any UNIX system should support the man command, and should have, on line, a complete copy of the UNIX Programmers' Manual, updated appropriately for that system. Any command that is documented as command(x) can be looked up using the command man x command.

The classic introduction to the UNIX system and a basic introduction to the system services and shell is included in the paper

"The UNIX Time-Sharing System" by D. M. Ritchie and K. Thompson in Communications of the ACM 17, 7 (July, 1974) 365-375.

For a look at the kind of effort required to retrofit old operating systems with small memory models to support a reasonably modern view of the kind of dynamic linking suggested by the example in Figure 8.9, see

"Programs as Higher Level Subroutines" by D. Jones, et al, in Software - Practice and Experience 9, 2 (Feb. 1979) 149-155.
This paper also includes a small example showing the different programs in a real user's environment with an indication of which programs dynamically load and call which others.