UnixWorld ``New To Unix'' Column: December 1988

Using the Unix Shell

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 friends and an 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 schedules, engineering reports, advertiser bilings, an other burdensome but vital paperwork on the university's batch-oriented IBM system. (It took many of the states 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 quota 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 resources, it helps you get the job done. That's what operating system software is supposed to do.

To the extents that software prevents you from doing what you want to do, it is a hindrance. Too many operating 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. I can't say the same about DOS, which, as often as not, prevents me from doing jobs that should be easy to do.

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 directly. 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 operating 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, as earlier installments of this column have shown. 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 (named 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 applications, 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 ($) followed 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 PS1 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 a 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 kernel to load and execute programs on your behalf. Commands fall into one of three classes -simple commands, pipeline commands, and commnad lists. In this installment, I describe simple commands; pipeline commands will be discussed next month. Commands can also be grouped into lists that execute sequentially or even conditionally. I'll delve into command lists in a future column.

A simple command is one that consists of a sequence of words separated by blanks. Here, a blank is one or more consecutive space or table 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 cp, require one or more file arguments--they are not optional.

Error Reports

Error reporting is also an important activity for the shell. If you type a command name incorrectly or issue a command that you don't have permission to execute, the shell tells you by displaying an error message. The messages are rather terse, but they usually contain enough information to tell you what went wrong.

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 prefix ``ksh:'' to both error messages to identify itself.

Listing 4 shows how the C shell responds to 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 example, nroff takes a file containing text and processing instructions 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 command 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 consume. 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 lesson10, for a course you are working on, along with a group of other files named lesson.grades, Alpha, and alpha.

One important wildcard character is the asterisk (*), which will match any set of adjacent characters. So if you want to list all files that begin with ``lesson,'' you would type:

ls lesson*

In this case lesson01 through lesson10 as well as lesson.grades will be listed.

Now say that you want to make a copy of only the lesson files in a different directory. To copy these, use the pattern lesson?? as the first file name argument to the cp command (and use a destination directory name). The pair of question marks specifies any two-character sequence, where each question mark matches a single character position. In this example, lesson.grades is not matched because it contains seven characters (not two) after the ``lesson'' text pattern.

In file-name generation, the shell also accepts character classes. A character class is a bracketed list of characters. The pattern [Aa]lpha matches a file named either Alpha or alpha. Don't forget that letter case is significant under UNIX, so Alpha and alpha are different file names. The character class [0-9] matches any single digit, and [a-z] matches any single lowercase letter. The dash specifies an inclusive range of characters.

To match any character not in the specified list or range, use an exclamation point as the first character to invert the sense of the character class. For example, [!A-Z]* is a pattern that matches any file name that does not start with a capital letter.

Alternative Shells

As you have seen, the UNIX shell is not part of the kernel of the operating system, but rather an external program. The shell is, therefore, easily replaceable. The great variety of UNIX shells attests to the ease with which a user can replace one shell with another. (Writing a shell, however, is not a simple job.)

Over the years, UNIX has had several different user shells. One of the earliest was the Mashey shell, written by namesake John Mashey. It was replaced by the Bourne shell (written by Steve Bourne) around the time UNIX went commercial. A popular replacement for the AT&T UNIX shell is the Berkeley C shell, which is so named because of its C-language-like programming syntax. It was written by Bill Joy while at UC Berkeley and incorporates a number of safety enhancements, a command history mechanism, command aliases, and other innovative features.

A more recent entrant gets my vote, in fact, it's one of the reasons I bought a 3B1 computer. The AT&T Korn shell, written by David Korn at Bell Labs, is compatible with its Bourne shell inspiration while incorporating a command-history mechanism and other C-shell-like features. It also adds a few of its own new wrinkles, such as true user-defined functions and numerous other enhancements to the shell programming feature set.

The described shells do a lot to help you work efficienty, but they don't do windows. Some classes of users are better served by visual shells that provide window and icon interfaces, which simplify their interactions with the system.

Macintoshes, PCs running Microsoft's Windows, Digital Research's GEM, or Quarterdeck's DESQview, and a variety of other hardware/operating system tandems have introduced millions of microcomputer users to iconic and windowing interfaces. Some of these users migrate to the command-oriented shells when they discover the power and flexibility such shells provide. However, many users stick with visual shells because that's all they need.

In a future ``New to UNIX'' column, we will examine several visual interfaces that are now making inroads into the predominantly command-oriented UNIX system arena. The availability of high-speed modems, and support for mice and other pointing devices is hastening the spread of the UNIX system from engineering and scientific laboratories into the office.

---

Copyright © 1995, 1996 The McGraw-Hill Companies, Inc. All Rights Reserved.

Edited by Becca Thomas / Online Editor / UnixWorld Online / editor@unixworld.com

Text entry and HTML markup by Arlene Lee
Last Modified: Friday, 03-May-96 13:17:52 PDT