By Augie Hansen

Whether an operating system helps or hinders your work depends largely on what you expect it to do. Here's a story to help illustrate this point. In the early 1960s, several frineds and I--students in the business, accounting, and engineering fields (I owned a slide rule)--pooled our talents to resurrect the nearly defunct campus radio station WRIU, at the University of Rhode Island. We licensed and constructed an FM station, got the closed-circuit AM station operational again, and went about getting advertisers and building an audience.

None of us was particularly fond of grunt work, though we all did plenty of it. To ease the bookkeeping effort, we introduced an innovation. We prepared program scedules, engineering reports, advertiser billings, and other burdensome but vital paperwork on the university's batch-oriented IBM system. (It took many of the state's commercial stations more than another decade to automate their business activities.)

Sure, we had to learn how to punch cards and deal with other IBM mainframe arcana, endure overnight processing times (the norm in those days), and suffer the subtle forms of abuse reserved for outsiders by the computer center personnel, but we got the job done.

That flashback sets the scene for this little tidbit, a quote by Harlan D. Mills: ``Software stands between the user and the machine.'' Mills' statement is obviously ambiguous. To the extent that software isolates you from the messy details of managing the hardware resources of a computer system while giving you access to those same resourcesa, it helps you get the job done. That's what operating system software is supposed to do.

To the extent that software prevents you from doing what you want to do, it is a hindrance. Too many opreating systems and user environments stand between you and the hardware in ways that hinder rather than help. Fortunately, the UNIX system is not among them.

Helpful Software

What? I can hear the groans now. You've read all those complaints about the awful UNIX interface. You've heard numerous "experts" tell you that UNIX is an antiquated operating system--a holdover from the dark ages of computing. Surely it must get in your way! And it certainly must be hard to use.

I contend that the UNIX system, in spite of its age, is very modern in its approach to computing and that it can help get you work done quickly and easily.

As a computer user, your feelings about a given system are formed by its user interface and application programs. You rarely--if ever--see the operating system dirctly. Indeed, the user interface is supposed to hide the operating system details from you.

Many new UNIX users who have prior DOS experience tend to compare the systems based on the typical applications they use. That's reasonable, and UNIX loses as surely as Nixon lost to Kennedy in the 1960 presidential TV debate. In its stock configurations, UNIX doesn't have a pretty face. No flashy, colorful screens, instant screen updates,or other features considered essential in the DOS world.

If you compare features of the opreating systems proper, UNIX is way ahead on points the UNIX prompt ($ or %) should be no more intimidating than the DOS A> prompt. To some degree, what you can do from the prompt on each system is similar. A major difference between DOS and UNIX is the power,flexibility, and scope of their user interfaces, the topic of this month's column.

In future installments, I will examine several major application programs that are equivalent, or at least behave similarly, in the two environments.

User Interfaces

The most visible part of the UNIX system-the part that prompts you for commands and appears to do your bidding-is the shell. This month I focus on the dominant UNIX system command-oriented shells: the Bourne shell (whose program file has the name sh), the Berkeley C shell (named csh), and the Korn shell (name ksh).

A shell is a user interface program. It is your agent in negotiations with the operating system that grants each logged-in user some portion of precious machine resources (processor time, memory, and access to peripheral devices). As shown in Figure 1, the shell and other programs, called applictions, sit atop the operating system kernel. The operating system kernel, in turn, sits atop the hardware, including the CPU, memory, and peripheral devices, such as disk drivers and communication ports.

The primary purposes of the shell, whichever you choose, are to provide prompting, command interpretation and execution, and error reporting Other features provided by a particular shell are bonuses. As you will see, the UNIX shells are versatile and packed with convenience features that go well beyond the big three listed here.

The Shell Prompt

The UNIX shell tells you when it is ready for your command by issuing a prompt. The default prompt for both the Bourne and Korn shells (both from the AT&T UNIX system) is a dollar sign ($) folowed by one space: the C shell (from the Berkeley UNIX system) uses a percent sign (%) followed by one space. The terminal cursor is initially positioned right after the space.

When you see the prompt, you can type a command and press the Return key to execute it. The shell redisplays the prompt when it is ready to accept another command. You can type commands even when the UNIX system is sending output to your screen. The system has a read-ahead capability, which stores what you type until it can respond. Although your input may appear jumbled with output, it is saved in the correct order and read when the system is ready for input.

You can customize the Bourne shell prompt by resetting the PSI shell variable to something else besides its default value (dollar sign, then a space). If you want to emphasize your dominance over the system, for example, use a prompt like ``yes, Master?'' or ``Your wish is my command!'' Listing 1A shows an example for resetting the Bourne shell prompt. Note that there should be no space around the equal sign and that double quotes surround the text string because it contains space.

The C shell prompt is stored in a variable appropriately named prompt. Listing 1B shows an example that resets a C shell prompt to the same string used in the Listing 1A example. Here the set command is used to set the variable named prompt to the value depicted in double quotes after the equal sign (=). Space around the equal sign is optional with the C shell.

A Command Interpreter

The essence of the UNIX shell is its use as a command interpreter. It arranges for the kernal to load and execute programs on your behalf. Commands fall into one of three classes--simple commands, pipeline commands, and command lists. In this installment, I describe simple commands; pipeline commands will be discussed next month. Commands can also be grouped into lists that execute sequentialy or even conditionally. I'll delve into command lists in a future column.

A simple commnad is one that consists of a sequence of words separated by blanks. Here, a blank is one or more consecutive space or tab characters, and a word is a sequence of non-blank characters. The first word of a command line is always the command name. In most cases, other words on a command line are passed as arguments to the named command. For example, without arguments, ls produces a list of files and directories for the current directory. However, if a directory name argument is given, ls lists the files in the named directory. For instance ls/usr/lib lists the files in the /usr/lib directory.

Other arguments, called options, are recognized by many UNIX commands and modify their behavior. A dash (-), which usually introduces an option, is called an option flag, although some commands accept the plus sign (+) as an option flag. The ls command rcognizes a number options that let you customize the output. For example, the -l (letter l, not numeral 1) option forces ls to produce a long listing, which shows permissions, sizes, modification, dates and times, and other information in addition to the name of each file in the specified directory.

Listing 2 shows a general format for a UNIX command. Here the brackets around option and filename indicate that they are optional entries, and the ellipses(...) indicate repetition. You don't type either the brackets or ellipses, but you may replace option or filename by actual values if appropriate for the case at hand. Note that some commands, such as , require one or more file arguments--they are not optional.

Error Reports

Listing 3 shows how the Bourne shell responds to these two error conditions-part A, mistyping the command name; and part B, lack of execute permission. Note that in neither case does the Bourne shell tell you it's program issuing these messages. However, the Korn shell would append ``ksh:'' to both error messages to identify itself.

Listing 4 shows how the C shell responds to the same two error conditions depicted in Listing 3. The messages are slightly more explanatory than the analogous ones for the Bourne shell. Also note that the C shell doesn't identify itself as the source of the error message.

Background Processing

An important feature of a multitasking operating system is the ability to do background processing. The task that you can interact with directly is the foreground task. Any other task is said to be in the background. Tasks suitable for background processing are non-interactives ones such as formatting text, compiling programs, printing form letters and address labels, and so on.

Listing 5 shows how to put a command in the background. In this excample, nroff takes a file containing text and processing instructios and produces output that contains formatted text, ready for printing. As we'll discuss in detail next month, the text./fmt directive tells the shell to take the output of the nroff ccommand and write it to the disk file named text.fmt. The ampersand (&) at the end of the command line instructs the shell to run the command as a background task.

It can take from several seconds to many hours to run a background task to completion. How long depends on the particular job at hand. What's important is that you can continue with other work in the foreground without waiting for the background task to complete.

Also, you an start more than one background task running at the same time. However, there is a practical limit--it depends on how much computing resources the task consumes. The more resources required, the fewer tasks you can run without significant system performance degradation.

By contrast, DOS is a single-tasking system. It can can do only one job at a time. Therefore, the only active DOS task is, by definition, the foreground task. Special programs called spoolers trick DOS into a form of rudimentary multitasking to allow background printing; however, that is a special case handled by a device driver or a terminate-and-stay-resident program and does not represent general-purpose multitasking.

File Name Generation

Another important feature of the UNIX shell is file name generation, or the selection of groups of file names used as command arguments. So instead of typing each file name individually, you can type characters common to the desired file names and then use file name matching (or wildcard) characters to indicate the characters that differ between the names. The shell creates the complete file name by locating the actual files that match the pattern you specify.

A few examples should help clarify. But first imagine you have a directory that contains a set of lesson files, named lesson01 through , for a course you are working on, along with a group of other files named