Web based School

Previous Page Main Page Next Page

  • 13 — C Shell

    • 13 — C Shell

      By John Valley

      As a UNIX user, you have a choice of shells available to you. These are the Bourne shell, the C shell, and the Korn shell. The C shell—the subject of this chapter—is one of the more popular shells available in UNIX. Chronologically, it was developed after the Bourne shell and before the Korn shell. The C shell incorporates many features of the Bourne shell and adds many new ones that make your UNIX sessions more efficient and convenient.

      There are advantages and disadvantages to each shell. You may wish to review Chapter 14, "Which Shell Is Right for You?" to help you decide which one to use.

      A Little History

      The Bourne and Korn shells were created at AT&T's Bell Labs, which, not coincidentally, is also where UNIX originated. Bell Labs is not the only organization that contributed to the development of UNIX, however. The Department of Computer Science at the Berkeley campus, University of California, played a very important role.

      As you might have already read, the early versions of UNIX were made available only to colleges and universities under a rather restrictive licensing arrangement: UNIX could be used outside of AT&T only for "research purposes." At Berkeley, interest in UNIX was very high. The computer science labs added many new features to UNIX and offered their version to other universities as well. The Berkeley version soon became the more popular version, not only because of its many new features and extensions, but also because Berkeley, unlike Bell Labs, offered maintenance and support to other user groups. Given this fact, it shouldn't be surprising that by the late 1970s, the BSD version (Berkeley Software Distribution) was the dominant variant of UNIX in use.

      One of the additions to UNIX was a new shell, written by Bill Joy (also the author of the vi text editor). Joy did not pattern his shell after the Bourne shell; indeed, to judge by results, he apparently felt that the Bourne shell syntax was clumsy and nonintuitive. As a syntax model, he chose the C programming language. The C shell commands, especially if, while, and the other structured programming statements, are somewhat similar in syntax to the equivalent statements in C. A shell is quite a different animal from a compiler, however, so the C programming language served only as a model; many forms and structures in the C shell have nothing to do with the C programming language.

      Because the C shell is not just an extension of the Bourne shell syntax, this chapter will cover all aspects of C shell operation; it can therefore be read independently from Chapter 11, "Bourne Shell," and Chapter 12, "Korn Shell."

      Invoking C Shell

      Each time you log in to UNIX, you're placed in an interactive shell referred to as your login shell. If your login shell is C shell, you can tell by its command-line prompt: the percent sign (%). The C shell prompt differs from the dollar sign prompt ($) of the Bourne shell to remind you that you're using the C shell. You can customize your keyboard prompt when using the C shell; for more information see the definition of prompt in the section titled "Variables" later in this chapter.

      If your login shell is not C shell, and C shell is available on your system, you can invoke it as an interactive shell from the command line. Even when you're already running the C shell, there will be times when you want to launch the C shell again, for example to run a shell script or to temporarily change the shell's options. To invoke the C shell interactively, use the following command:

      $ csh %
      NOTE: The csh command is usually located in either the /bin or the /usr/bin directory. Because both directories are usually in your search path, you shouldn't have any trouble finding the csh command if your system has it. If you don't find it right away, you might look in the directory /usr/ucb (standard home for BSD components in a UNIX System V system), or in /usr/local/bin, home for programs your shop has acquired that weren't provided with the original system. Remember, though, that the C shell was for many years available only to those shops using the BSD variant of UNIX; unlike the Bourne shell, there is no guarantee that you will have the csh command on your system.

      The csh command also supports a number of options and arguments (described later in this chapter in the section titled "Shell Options"), but most of them are not relevant to running an interactive shell.

      Whenever csh is invoked, whether as the login shell or as a subshell, it loads and executes a profile script named .cshrc. If it is a login shell, the C shell will also execute a profile script on startup named .login, and another on exit named .logout. Note that the .login script is executed after .cshrc, not before. For additional information about C shell profile scripts, see the section titled "Customizing Your Shell Environment" later in this chapter.

      Most versions of the C shell import environment variables such as PATH into local array variables at startup. The C shell does not refer to the public environment variables (including PATH) for its own operation. This means that usually you'll want to maintain the path variable for directory searches, not PATH. Some versions of the C shell do not properly import environment variables, with confusing results. If it appears that you have no search path set, but the PATH variable is set and accurate (as shown by echo $PATH), check that the variable path has a matching value. If not, you'll need to import critical environment variables into local variables yourself.

      NOTE: If you are familiar with Bourne shell, you won't notice much difference working with the C shell unless you use advanced shell features such as variables, command replacement, and so on.

      Important differences do exist, however. Among these are the set of punctuation characters having special meaning to the shell (often called metacharacters). The C shell is sensitive to all the special characters of the Bourne shell, as well as the tilde (~), the commercial at sign (@), and the exclamation point (!). Don't forget to quote or escape these characters when writing commands unless you intend their special shell meaning. (See the section "Quoting and Escaping from Special Characters" for a discussion of the details.)

      Shell Basics

      When you enter commands at the shell prompt, you are providing input to the shell. The shell sees a line of input as a string of characters terminated with a newline character that is usually the result of pressing return on your keyboard. That input can be anything from a single, simple command to multiple commands joined with command operators. Each command line that you enter is actually a shell statement. In addition to providing input to the shell manually by entering shell statements on the command line, you can also provide input to the shell by putting shell statements into a file and executing the file.

      The next section covers the basics of interacting with the shell by entering shell statements on the command line. (Of course, anything that you can enter on the command line can also be put into a file for later, "canned" execution. Such files are called shell scripts.) The section following is titled "Shell Statements—A Closer Look," which provides a more detailed, technical look at components of shell statements. If you plan to write shell scripts, you'll definitely want to read this section.

      When you finish this section, you will feel like you know a lot about the shell, but this is just the beginning. In addition to its basic service of providing a means to instruct the computer, the shell also provides a number of tools you can use to expedite your work flow. These tools, or features of the shell, are described in subsequent sections of this chapter.

      Executing Commands—The Basics

      C shell accepts several types of commands as input: UNIX commands, built-in shell commands, user-written commands, and command aliases. This section describes the different types of commands you can execute and the various ways you can execute commands.

      Command Names as Shell Input

      As you know, you execute a command by entering the command's name. The C shell supports any of the following as command names:

      • Built-in C shell command. The shell provides a number of commands implemented within the shell program itself: invoking a built-in command therefore executes very quickly because no program files need to be loaded. A built-in command is always invoked by a simple name, never by a pathname.

        Because the shell first checks a command name for built-in commands before searching for a file of the same name, you cannot redefine a built-in command with a shell script. The next section, "Built-In Shell Commands," briefly describes each one; detailed descriptions with examples of how to use these commands are presented in the task-oriented sections of this chapter.

      • Filename. You can specify the filename or a relative or absolute pathname of a file as a command. The file must be marked executable and must be either a binary load file or a shell script in the C shell language. The C shell cannot process shell scripts written for the Bourne or Korn shells. (See the section titled "Shell Programming" later in this chapter for notes about using shell scripts with the C shell.)

        All UNIX commands are provided as executable files in the /bin or /usr/bin directories. You invoke a UNIX command by entering its filename or full pathname.

        Examples of invoking an executable program file include the following:

        % cat big.script
        % /usr/bin/cat big.script
        % /usr/ucb/cc myprog.c
        % ../paylist paymast

      • Command alias. A command alias is a name you define using the alias shell built-in command.

        An alias can have the same name as a shell built-in command or an executable file. You can always invoke an executable file having the same name as an alias by using the file's full pathname. An alias having the same name as a built-in command, however, effectively hides the built-in command. Aliases are described in detail in the section titled "Aliases" later in this chapter.

      Built-In Shell Commands

      C shell provides a number of commands implemented within the shell program itself. Built-in commands execute very quickly because no external program file needs to be loaded. Table 13.1 lists the commands alphabetically along with a brief description of each one. The remainder of this chapter groups these commands into subsections dedicated to particular tasks you'll perform in the shell and describes how to use each command.

        Table 13.1. Built-in commands for C shell.


      Define or list a command alias


      Background execution


      Breaking out of a loop


      Exit from a switch statement


      Begin a case in switch


      Change directory


      Change directory


      Begin the next loop iteration immediately


      Label for the default case in switch


      List the directory stack


      Echo arguments to standard output


      Rescan a line for substitutions


      Invoke a new shell


      Exit from the current shell


      Switch a job to foreground execution


      Looping control statement


      Echo arguments to standard output


      Alter the order of command execution


      Print hash table statistics


      List command history


      Conditional execution


      List active jobs


      Signal a process


      Respecify maximum resource limits


      Invoke the system login procedure


      Exit from a login shell


      Change your group ID


      Control background process dispatch priority


      Prevent termination on logout


      Request notification of background job status changes


      Process interrupt within a shell script


      Return to a previous directory


      Change directory with pushdown stack


      Rehash the directory search path


      Repetitively execute a command


      Display or change a variable


      Set environment variable


      Shift parameters


      Interpret a script in the current shell


      Stop a background job


      Stop the current shell


      Conditional execution


      Time a command


      Display or set the process file creation mask


      Delete a command alias


      Disable use of the hash table


      Cancel a previous limit command


      Delete shell variables


      Delete environment variables


      Wait for background jobs to finish


      Looping control


      Foreground execution


      Expression evaluation

      Executing Simple Commands

      The most common form of input to the shell is the simple command, where a command name is followed by any number of arguments. For example, in the following command line

      % chdir dirname

      chdir is the command and dirname is the argument. It is the responsibility of the command, not the shell, to interpret the arguments. Many commands, but certainly not all, take the form

      % command -options filenames

      Although the shell does not interpret the arguments of the command, the shell does make some interpretation of the input line before passing the arguments to the command. Special characters entered on a command line cause the shell to redirect input and output, start a different command, search the directories for filename patterns, substitute variable data, and substitute the output of other commands.

      Entering Multiple Commands on One Line

      Ordinarily, the shell interprets the first word of command input as the command name and the rest of the input as arguments to that command. The semicolon (;) directs the shell to interpret the word following the symbol as a new command, with the rest of the input as arguments to the new command. For example, the command line

      % who -H; df -v; ps -e

      is the equivalent of

      % who -H % df -v % ps -e

      except that in the second case the results of each command would appear between the command input lines.

      When the semicolon is used to separate commands on a line, the commands are executed in sequence. The shell waits until one command is complete before executing the next. You can also execute commands simultaneously (see the section titled "Executing Commands in the Background") or execute them conditionally, which means that the shell executes the next command only if the first command succeeds or fails (see the section titled "Executing Commands Conditionally").

      Entering Commands Too Long for One Line

      Sometimes command lines get quite lengthy. On some terminals, when you reach the edge of the display screen the input autowraps to the next line, but depending on terminal settings, some do not. It would be nice if you could type part of a command on one line and enter the remainder of the command on a second line. This can be accomplished by escaping the newline character.

      Remember that the shell sees a line of input as a statement terminated with a newline character. But the newline character is also considered to be a white space character. If you end a line with a backslash (\), the next character—the newline character—will be treated literally, meaning that the shell will not interpret the newline character as the end of the line of input.

      % echo Now is the time for all good men \_ to come to the aid of the party. Now is the time for all good men to come to the aid of the party.
      Executing Commands in the Background

      Normally when you execute commands, they are executed in the foreground. This means that the command has the system's undivided attention, and you can't do anything else until the command finishes executing. For commands that take a long time to execute, however, this can be a problem. To free your system without waiting for the command to finish, you can execute the command in the background by putting an ampersand (&) at the end of the command:

      % who -H & [1] + Running who -H & %

      You also can run multiple commands in the background simultaneously:

      % who -H & df -v & ps -e &

      A command executing in the background is referred to as a job, and each job is assigned a job number—the bracketed number in the preceding example. C shell provides you with several commands for managing background jobs; see the section later in this chapter titled "Job Control."

      Repetitively Executing a Command—repeat

      You can use the repeat command to execute some other command a specified number of times. While the repeat command doesn't see frequent use, it can on occasion be quite handy. For example, if you had stored some text in a model file, and wanted to make five copies of it, you could do so easily with the command

      repeat 5 cat model.txt new.txt

      Or, if you were writing a shell script to print a document, you might use the command

      repeat 5 echo *******************************

      to mark its first page clearly as the start of the document.

      The syntax of the repeat command is as follows:

      repeat count command

      For count, specify a decimal integer number. A count of zero is valid and suppresses execution of the command.

      For command, specify a simple command that is subject to the same restrictions as the first format of the if statement. The command is scanned for variable, command, and history substitutions, filename patterns, and quoting. It cannot be a compound command, a pipeline, a statement group (using {}), or a parenthesized command list.

      Any I/O redirections are performed only once regardless of the value of count. For example, repeat 10 echo Hello >hello.list would result in ten lines of Hello in a file named hello.list.

      Executing Commands in a Subshell—()

      A command (or a list of commands separated with semicolons) enclosed in parentheses groups the command or commands for execution in a subshell. A subshell is a secondary invocation of the shell, so any change to shell variables, the current directory, or other such process information lasts only while executing the commands in the group. This is a handy way, for example, to switch to another directory, execute a command or two, and then switch back without having to restore your current directory:

      % (cd /home/bill; cp *.txt /home/john)

      Without the parentheses, you would have to write:

      % cd /home/bill % cp *.txt /home/john % cd /home/john

      The syntax for grouping commands is:

      ( commands )

      Enclosing a list of commands in parentheses is a way to override the default precedence rules for the &&, ||, and | operators, at the expense of invoking a subshell and losing any environmental effects of the commands' execution. For example, (grep || echo) | pr will pipe the output of the grep command, and possibly that of echo if grep sets a nonzero exit code, to the pr command.

      I/O redirections can be appended to the subshell just as for a simple command; the redirections are in effect for all of the commands within the subshell. For example, (cat; echo; date) > out will write the output of the cat, echo, and date commands to a file named out without any breaks. If you look at the file afterward, first you'll see the lines written by cat, followed by the lines written by echo, and finally the lines written by date. Similarly, input redirections apply to all commands in the subshell, so that each command in turn reads lines from the redirected file, starting with the line following those read by any previously executed commands in the subshell.

      Executing Commands Conditionally

      Compound commands are actually two or more commands combined together so that the shell executes all of them before prompting (or, in the case of shell scripts, reading) more input.

      Compound commands are not often needed for work at the keyboard, and you'll rarely feel the lack if you don't understand or don't use compound commands. However, compound commands form a very useful extension to the shell's syntax, especially in shell scripts. Some compound command formats, such as & (background job) and | (the pipe operator) are essential to effective work with UNIX.

      Conditional Execution on Success—&& (And)

      The double ampersand operator (read and) is used to join two commands: command1 && command2. It causes the shell to execute command2 only if command1 is successful (has a zero exit code).

      For command1 or command2, you can write a simple command or a compound command. The && operator has higher precedence than || but lower precedence than |. For example,

      grep '#include' *.c | pr && echo OK

      will echo OK only if the pipeline grep | pr sets a zero exit code. (For pipelines, the exit code is the exit code of the last command in the pipeline.)

      The compound command cp file1.c file1.bak && rm file1.c shows the possible benefit of using &&: The rm command will delete file1.c only if it is first successfully copied to file1.bak.

      Conditional Execution on Failure —|| (Or)

      The or operator is used to join two commands: command1 || command2. It causes the shell to execute command2 only if command1 failed (set a nonzero exit code).

      For command1 or command2, you can write a simple command or a compound command. The || operator has lower precedence than both the && and | operators. For example, in the following command

      grep '#include' *.c || echo No files | pr

      either grep succeeds, or else the words No files are piped to the pr command. That is, the pipe is between the echo and pr commands, not between grep (or grep || echo) and pr.

      Use the || operator to provide an alternative action. For example, in the following case, if the mkdir command fails, the exit command prevents further execution of the shell script:

      mkdir $tmpfile || exit

      Shell Statements—A Closer Look

      A command is either a basic command, or a basic command embellished with one or more I/O redirections.

      A basic command is a series of words, each subject to replacements, which when fully resolved specifies an action to be executed and provides zero or more options and arguments to modify or control the action taken. The first word of a basic command, sometimes called the command name, must specify the required action.

      In plainer terms, a statement is the smallest executable unit. When the shell is operating in interactive mode, it displays its prompt when it requires a statement. You must continue to enter shell statement components, using multiple lines if necessary, until you have completed a full statement. If the statement is not completed on one line, the shell will continue to prompt you, without executing the line or lines you have entered, until it has received a full statement.

      Shell statements are formed from a number of tokens. A token is a basic syntactic element and can be any of the following:

      • Comments. A comment begins with any word having a pound sign (#) as its first character, and extends to the end of the line. This interpretation can be avoided by enclosing the pound sign (or the entire word) in quotes. (See "Quoting and Escaping Special Characters" later in this chapter.)

      • White space. White space consists of blanks and tabs, and sometimes the newline character. White space is used to separate other tokens which, if run together, would lose their separate identity. Units of text separated by white space are generically called words.

      • Statement delimiters. Statement delimiters include the semicolon (;) and the newline character (generated when you press return). You can use the semicolon to run commands together on the same line. The shell treats the commands as if they had been entered on separate lines.

        Normally every command or shell statement ends at the end of the line. The return (or Enter) key you press to end the line generates a character distinct from printable characters, blanks and tabs, which the shell sees as a newline character. Some statements require more than one line of input, such as the if and while commands. The syntax description for these commands shows how they should be split over lines; the line boundaries must be observed, and you must end each line at the indicated place or else you will get a syntax error.

      • Operators. An operator is a special character, or a combination of special characters, to which the shell attaches special syntactic significance. Operators shown as a combination of special characters must be written without white space between them, otherwise they will be seen as two single operators instead of the two-character operator.

        Punctuation characters having special significance to the shell must be enclosed in quotes to avoid their special interpretation. For example, the command grep '#' *.c uses quotes to hide the pound sign from the shell so that the pound sign can be passed to grep as an argument. See the section later in this chapter titled "Quoting and Escaping from Special Characters" for details about using quotes.

      • Words. A word is any consecutive sequence of characters occurring between white space, statement delimiters, or operators. A word can be a single group of ordinary characters, a quoted string, a variable reference, a command substitution, a history substitution, or a filename pattern; it can also be any combination of these elements. The final form of the word is the result of all substitutions and replacements, together with all ordinary characters, run together to form a single string. The string is then used as the command name or command argument during command execution.

      Filename Substitutions (Globbing)

      Filename generation using patterns is an important facility of the Bourne shell. The C shell supports the filename patterns of the Bourne shell and adds the use of {} (braces) to allow greater flexibility.

      Several shell commands and contexts allow the use of pattern-matching strings, such as the case statement of switch and the =~ and !~ expression operators. In these cases, pattern strings are formed using the same rules as for filename generation, except that the patterns are matched to another string.

      When any of the pattern expressions described below are used as arguments of a command, the entire pattern string is replaced with the filenames or pathnames that match the pattern. By default, the shell searches the current directory for matching filenames, but if the pattern string contains slashes (/), it searches the specified directory or directories instead. Note that several directories can be searched for matching files in a single pattern string: a pattern of the form dir/*/*.c will search all the directories contained in dir for files ending with .c.


      The asterisk matches any string of characters, including a null string. Used by itself, it matches all filenames. Used at the beginning of a pattern string, it means that leading prefixes of the filename pattern are ignored: *.c matches any filename ending with .c. Used at the end of a pattern string, it means that trailing suffixes of the filename pattern are ignored: s.* will match s.main, s.prog.c, and any filename beginning with s.. Used in the middle of a pattern, it means that matching filenames must begin and end as shown but can contain any character sequences in the middle: pay*.c matches filenames beginning with pay and ending with .c, such as payroll.c, paymast.c, and paycheck.c.


      The question mark matches any one character. For example, ? as a complete word will match all filenames one character long in the current directory. The pattern pay?.c will match pay1.c and pay2.c but not payroll.c. Multiple question marks can be used to indicate a specific number of don't-care positions in the filename: pay??.c will match filenames beginning with pay and containing any two characters before .c, such as pay01.c and paybb.c, but will not match payroll.c.


      The square brackets enclose a list of characters. Matching filenames contain one of the indicated characters in the corresponding position of the filename. For example, [abc]* will match any filename beginning with the letter a, b, or c. Because of the asterisk, the first character can be followed by any sequence of characters.

      Use a hyphen (-) to indicate a range of characters. For example, pay[1-3].c will match filenames pay1.c, pay2.c, and pay3.c, but not pay4.c or pay11.c. Multiple ranges can be used in a single bracketed list. For example, [A-Za-z0-9]* will match any filename beginning with a letter or a digit. To match a hyphen, list the hyphen at the beginning or end of the character list: [-abc] or [abc-] will match an a, b, c, or hyphen.

      Use a circumflex (^) after [ to negate the range of characters. The pattern [^a-zA-Z0-9]* will match all filenames that do not begin with a letter or digit—that is, filenames beginning with a punctuation character such as .c or #myfile.txt.


      Braces enclose a list of patterns separated by commas. The brace expression matches filenames having any one of the listed patterns in the corresponding position of the name. For example, the pattern /usr/home/{kookla,fran,ollie}/.profile expands to the path list /usr/home/kookla/.profile /usr/home/fran/.profile /usr/home/ollie/.profile. Unlike *, ?, and [], brace-enclosed lists are not matched against existing filenames; they are simply expanded into filenames regardless of whether the corresponding files exist. Brace-enclosed lists can be nested, for example /usr/{bin,lib,home/{john,bill}} refers to any of the directories /usr/bin, /usr/lib, /usr/home/john, and /usr/home/bill.

      The tilde (~) can be used at the beginning of a word to invoke directory substitution. The tilde forms are as follows:


      Substituted with the full pathname of your home directory. Also used in the form ~/path to refer to a file or directory under your home directory.


      Substituted with the full pathname of user name's home directory. For example, ~ken/bin refers to /usr/ken/bin if the home directory for user ken is /usr/ken. The password file /etc/passwd is searched for name to determine the directory pathname; if name is not found, the shell generates an error message and stops.

      If the tilde does not appear by itself as a word, and is not followed by a letter or by a slash, or appears in any position other than the first, it is not replaced. Thus, /usr/marta/~file.c is a reference to the file ~file.c in the directory /usr/marta.

      It is important to realize that filename generation using pattern strings causes a replacement of one word with many. A filename pattern must be a single word. The ordinary characters and pattern-matching characters in the word describe a rule for choosing filenames from the current or specified directory. The word is replaced with each filename or pathname found that matches the pattern. Consider the following examples:

      % echo Files: *.txt Files: ch1.txt ch2.txt chlast.txt % set files=(*.txt) % echo Found $#files files Found 3 files % echo $files[2] ch2.txt mkdir $tmpfile || exit

      Redirecting Input and Output

      C shell provides several commands for redirecting the input and output of commands. You might already be familiar with the input (<) or output (>) redirection characters from earlier chapters. C shell provides you with these and more.

      An I/O redirection is an instruction to the shell you append to a command. It causes one of the standard file descriptors to be assigned to a specific file. You might have previously encountered standard files in the discussion of the Bourne shell (Chapter 11). The UNIX operating system defines three standard file descriptors: standard input, standard output, and standard error. (These names are sometimes abbreviated to stdin, stdout, and stderr.)

      NOTE: The UNIX operating system actually provides at least twenty-five file descriptors for use by a command. It is only by convention that the first three are set aside for reading input, writing output, and printing error messages. Unless you instruct otherwise, the shell always opens these three file descriptors before executing a command, and assigns them all to your terminal.

      A file descriptor is not the file itself. Rather, it is a channel, much like the phone jack on the back of your stereo: you can connect it to any audio source you like. Similarly, a file descriptor such as standard input must be connected to a file—your terminal by default, or the disk file or readable device of your choice.

      You can change the location where a command reads data, writes output, and prints error messages, using one or more of the I/O redirection operators. The operators are shown in Table 13.2.

        Table 13.2. I/O redirection operators.

      Input Redirection

      < filename

      Use the contents of filename as input to a command.

      << word

      Provide shell input lines as command input. Lines of the shell input which follow the line containing this redirection operator are read and saved by the shell in a temporary file. Reading stops when the shell finds a line beginning with word. The saved lines then become the input to the command. Of course, the lines read and saved are effectively deleted from the shell input, and will not be executed as commands; they are effectively "eaten" by the << operator. Shell execution continues with the line following the line beginning with word. If you use the << operator on a command you type at the terminal, be careful: lines you type afterward will be gobbled up by the shell—not executed—until you enter a line begining with whatever you specified as word. The << operator is most often used in shell scripts.

      Output Redirection

      > filename

      Write command output to filename

      >! filename

      Write command output to filename, and ignore the noclobber option. The noclobber option is fully explained in the section "Using Predefined Variables" later in this chapter. Briefly it causes the shell to disallow the > filename redirection when filename already exists; noclobber is therefore a safety you can use to prevent your accidentally destroying an existing file. Of course, sometimes you want to redirect output to a file even though it already exists. In such a case, you must use the >! operator to tell the shell you really want to proceed with the redirection. If you don't set the noclobber option, then you won't need to use the >! operator either.

      >& filename

      Open filename and write both the command output and error messages to it

      >&! filename

      Open filename and write both the command output and error messages to it, and ignore the noclobber option

      >> filename

      Open filename and write command output at the end of the file (append mode)

      >>! filename

      Open filename and write command output at the end of the file (append mode), and ignore the noclobber option

      >>& filename

      Open filename and write command output and error messages at the end of the file (append mode)

      >>&! filename

      Open filename and write command output and error messages at the end of the file (append mode), and ignore the noclobber option

      In Table 13.2, filename represents any ordinary filename or pathname, or any filename or pathname resulting after variable substitution, command substitution, or filename generation.

      I/O redirection operators are appended to a command; for example, date >curdate will write the current date to the file curdate instead of to your terminal. You can also use more than one redirection per command: simply list them one after another at the end of the command. The order doesn't matter: for example, both cat <infile >outfile and cat >outfile <bigfile will have the same effect.

      Input Redirection

      Some commands make no special use of the standard input file, such as the date and the ls system commands; others require an input file to function properly, such as the cat and awk commands. You can use the < redirection operator in the form command < filename to designate a file as the source of input for commands like cat and awk; if you do not, these commands will read data from your keyboard—sometimes useful, but usually not. If you provide an input redirection, but the command does not read data (such as ls), the I/O redirection is still performed by the shell, it is just ignored by the command.

      It is an error to redirect standard input to a file that doesn't exist.

      The redirection << word is a special form of the input redirection operator. Rather than taking input from a file, input to the command comes from the current shell input stream—your keyboard, if you append << to a command you type in, or your shell script if you use << on a command in a shell script.

      For word, you choose an arbitrary string to delimit the lines of input. Then write the lines to be provided to the command as input immediately following the command line, and follow the last line with a line beginning with word. The shell reads the lines ahead, stores them in a temporary file, and sets up the temporary file as standard input for the command.

      This form of input redirection is called a here document, because it is located here, in line with your shell commands. It is useful when you want to provide predefined data to a command, and it saves you from having to create a file to hold the data.

      Unlike the filename part of other I/O redirection operators, word for the here document is not scanned for variable references, command substitutions, or filename patterns; it is used as is. Also, the following shell input lines are checked for the presence of word as the first word of the line before any substitutions or replacements are performed on the line.

      Normally, lines of the here document are checked for variable references and command replacements; this allows you to encode variable information in the here document. If you quote any part of word, however, the lines are read and passed to the command without modification. For example, the redirection << STOP reads lines up to STOP, and performs substitutions on the lines it reads; the redirection << "STOP" reads lines up to the line beginning with STOP, and passes the lines directly to the command, as is, without substitutions or replacements of any kind.

      The line beginning with word is discarded, and neither passed to the command in the here document, nor executed by the shell.

      The following example shows the use of a here document to print a customized message:

      pr << HERE | lp Hello, $user. Your print job, 'lpstat' has been scheduled for output at a later time. Please contact Joe if you have any questions. HERE

      The line containing the word HERE will not appear in the output message; it is simply a mark to let the shell know where the redirected lines end.

      Output Redirection

      Output redirections have the general form > and >>. The first operator creates a new file of the specified name. The file is opened before command execution begins, so even if the command fails, or cannot be found, or if the shell finds an error on the command line and stops, the output file will still be created.

      If you've set the noclobber option (with set noclobber), then the shell will refuse to create the named output file if it already exists; doing so would destroy its current contents. If you want to perform the output redirection even if the file filename already exists, use the redirection operator >! instead; it overrides the noclobber option.

      The >> command arranges for command output to be added to the end of the named file. For this redirection operator, the noclobber option requires that the named file already exist. If you use the alternate form >>!, or if you use >> and the noclobber option is not set, the shell will create the named file if necessary.

      The >& and >>& operators redirect both the standard output and standard error files to filename. The Bourne shell allows you to redirect the standard output and standard error files separately; the C shell does not. Actually, this is not much of a limitation in real life.

      If you have the noclobber option set, you'll need to use >&! instead of >& to proceed even if the named file exists, or >>&! to proceed even if the named file doesn't exist.

      NOTE: For purposes of understanding shell syntax, it might be noted that appending an I/O redirection to a simple command yields a simple command. Except where specifically prohibited, a command with redirections appended can be used wherever a simple command is allowed, such as on the single-line if statement.

      Quoting or Escaping from Special Characters

      As you've seen from previous sections, certain characters have special meaning for the shell. That is, when the shell encounters a special character, it will perform the action that the special character calls for. The following punctuation characters available on the standard keyboard are special to the shell and disrupt the scanning of ordinary words:

      ~ ' ! @ # $ % ^ & * ( ) \ | { } [ ] ; ' " < > ?

      In some contexts, particularly within the switch statement, the : (colon) is also a special character. The colon is recognized as a special character only when expected, in a case or default statement, and as a statement label. It does not need to be quoted except to avoid these specific interpretations.

      To use one of these characters as a part of a word without its special significance, you can escape the character by placing a backslash (\) immediately in front of the character. Note that a backslash intended as an ordinary character must be written as two backslashes in succession: \\. To escape a two-character operator such as >>, you must insert a backslash in front of each character: \>\>.

      Alternatively, you can enclose the special character or any portion of the word containing the character in quotes. The shell recognizes three kinds of quotes: the apostrophe ('), the quote ("), and the backquote (`).

      Use two apostrophes (also called single quotes) to enclose a character sequence and avoid all interpretation by the shell. I often call a string enclosed in apostrophes a hard-quoted string, because the shell performs absolutely no substitution, replacement, or special interpretation of anything appearing between the apostrophes. Even the backslash character is treated as an ordinary character, so there are no escapes within an apostrophe-enclosed string, and you cannot embed an apostrophe in such a string. That is, the string 'who's there' will cause a shell error: the shell will see this as who concatenated with an s, followed by a white space delimiter, followed by a word beginning with there, and then the starting apostrophe of another string. The third apostrophe starts a quoted string that the shell will follow over as many lines as necessary to find an ending apostrophe, probably eating up shell lines you intended as commands, and eventually yielding a shell syntax error or an erroneous command execution.

      One of the uses of quoted strings is to specify a single word containing blanks, tabs, and newline characters. For example, the following shows the use of a single echo command to print two lines of output:

      % echo -n 'Hello. Please enter your name: ' Hello. Please enter your name:

      The double apostrophe or quote (") also provides a special bracket for character strings. Like the apostrophe, the quote hides most special characters from the shell's observation. Quoted strings, however, are subject to two kinds of scan and replacement: variable references and command substitutions.

      Any of the reference forms for shell variables ($1, $name, ${name}, $name[index], $*, and others) are recognized inside quoted strings and are replaced with the corresponding string value. The replacement occurs inside the quoted string, leaving its unity as a single word intact (even if the substituted value includes blanks, tabs, or newline characters).

      Command substitution occurs for strings enclosed in backquotes ('). The entire string enclosed between matching backquotes is extracted and executed by the shell as if it were an independent command. The command can be two or more commands separated with semicolons, or a pipeline, or any form of compound statement. Any data written to standard output by the command is captured by the shell and becomes the string value of the backquoted command. The string value is parsed into words, and the series of words replaces the entire backquoted string.

      All forms of shell substitution will occur inside backquoted command strings, including variable replacement, nested command executions, history substitutions, and filename patterns. Nested command strings will work, but the backquotes introducing them must be escaped with \ to hide them from the shell's first scan of the backquoted string.

      A backquoted command string (or any number of them) can appear inside a quoted string and will have its normal effect; this is the second form of substitution performed on "-quoted strings. A quoted command substitution ("xxx`commands`xxx") generates new words only at the end of each line, except at the end of the last line. If the executed command prints only one line of text, the text replaces the backquoted expression without introducing any word breaks.

      Both quoting forms '...' and "..." suppress filename generation. For example, note the difference in the following echo commands:

      % echo *.c main.c io.c parse.c math.c % echo "*.c" *.c

      Apostrophes and quotes can appear inside a double-quoted string. The double quote must be escaped with a backslash to prevent premature termination of the quoted string (for example "He said, \"John!\""). The apostrophe has no special significance when appearing inside a double-quoted string and does not need to be backslashed. The following example shows the use of quotes inside quoted strings:

      % echo "He said, \"John!\"" He said, "John!" % echo "Filename: '$1'" Filename: '/usr/bin/ls'

      A backslash appearing inside an apostrophe-quoted string is retained and appears in the string's value, because no substitutions occur inside an apostrophe-quoted string. Inside a double-quoted string or a command substitution using ', or in a normal unquoted word, a backslash has the effect of suppressing shell interpretation of the character that follows it; the backslash is then removed from the string. The following examples show the effect of a backslash in all these contexts:

      % echo "Double \" quote" Double " quote % echo Double \" quote Double " quote % echo 'Single \' quote Single \ quote % echo Single \' quote Single ' quote

      Working with Directories and the Directory Stack

      C shell provides you with several built-in commands for working with directories. The cd, chdir, pushd, and popd commands all change the current directory in one way or another.

      The pushd and popd commands provide a pushdown stack mechanism for changing directories, and the dirs command displays the contents of the stack. If you switch to another directory using pushd instead of cd, the pathname of your previous directory is "saved" in the directory stack. A subsequent popd will then return you to the previous directory. Be aware that the cd command does not maintain the directory stack; you cannot use popd to return to a directory that you left using cd.

      Changing Directories—cd and chdir

      In C shell, you can choose from two commands for changing your current working directory: cd and chdir. The chdir command is equivalent to cd in every way. The syntax for these commands is as follows:

      cd [ name ] chdir [ name ]

      If you omit the name argument, the command attempts to change to the directory whose pathname is given by the value of the C shell variable home; see the section later in this chapter titled "Using Predefined Variables" for more about home.

      If you specify a name, the cd or chdir command uses a search hierarchy to attempt to locate the referenced directory, as follows:

      1. If name begins with /, ./, or ../, the command attempts to switch to the named directory; failure terminates the command immediately. In other words, if you use a relative or absolute pathname, the specified directory must exist and must be accessible to you, otherwise the command fails.

      2. The command searches your current directory. A partial pathname, of the form name1/name2/.../namen implies searching your current directory for the entire subtree.

      3. If the directory path cannot be found in your current directory, the command checks to see if the variable cdpath exists and has a value. If it does, then each of the directories named in cdpath is checked to see if it contains name. If successful, the command changes to the name in that directory and prints the full pathname of the new current directory.

      4. If no variable cdpath exists, or if name cannot be found in any of the directories listed in cdpath, the command checks to see if name is a variable name and has a value beginning with /. If so, the command changes to that directory.

      5. If name still cannot be found, the command fails.

      For more information about the cdpath variable, see the section titled "Using Predefined Variables" later in this chapter.

      The cd and chdir commands as implemented by the C shell provide a great deal of flexibility in generating shortcuts for directory names. There is nothing more painful than having to repeatedly type long directory names on the cd command. The purpose of the cd command's search hierarchy is to provide some mechanisms you can use for shortening a reference to a directory name. The cdpath variable is your principal tool: if you set it to a list of directories you often reference, you can switch to one of those directories just by giving the base directory name. If cdpath is not sufficiently flexible to suit your needs, you can define a shell variable as an alias for a directory's full pathname, then cd varname will switch you to that directory for the price of a few keystrokes.

      NOTE: When using a shell variable as a pseudonym for a directory path, you do not need to write $ in front of the variable name; doing so is permitted and also works because of the shell's variable substitution mechanism but is not required.

      Listing the Directory Stack—dirs

      The directory stack is a mechanism by which you can store and recall directories you have changed to using the special change-directory commands pushd and popd, discussed in the next two sections. The dirs command lists the directories in the directory stack:

      % dirs /usr/home/john/bin /usr/home/john /usr/home/john/docs

      Three directories are on the directory stack in this example for user john. The first directory listed is the current directory (the one you would see if you entered the pwd command). Directories to the right are previous directories, the farthest to the right being the least recent. In this example, the directory /usr/home/john/docs was the first directory to be changed to—that is, "pushed" onto the pushdown directory stack, /usr/home/john was the next directory, and /usr/home/john/bin was the directory most recently changed to (the current directory).

      Changing to a Directory Using the Directory Stack—pushd

      To save the pathname of a directory on the directory stack, use the pushd command to change to another directory. Using pushd saves the pathname of your previous directory on the directory stack so that you can return to the previous directory quickly and easily using the popd command. Use dirs to display the directories currently saved on the pushdown stack.

      There are three forms of the pushd command:

      pushd pushd name pushd +n

      Used in the form pushd, the command exchanges the top two directory stack elements, making your previous directory the current and your current directory the previous. Successive pushd commands used without an argument therefore switch you back and forth between the top two directories.

      Used in the form pushd name, the command changes to directory name in the same way as cd would have; pushd uses the cdpath directory list to resolve name, and succeeds or fails in the same cases as cd. The pathname of the current directory is saved in a directory stack prior to the change. The directory stack is an implicit array variable maintained by the shell (which you cannot access directly) so that each pushd adds the current directory on the left and pushes all existing entries to the right; the top (or first) element is always your current directory, and subsequent entries are the pathnames of your previous directories in reverse order. The popd command discards the top stack entry and changes to the new top entry, reducing the total number of items stacked by one.

      Use the form pushd +n to do a circular shift of the directory stack by n positions, changing to the new top directory. A circular shift treats the list of elements as if they were in a ring, with the first preceded by the last and the last followed by the first; the shift changes your position in the ring without deleting any of the elements. Consider the following example:

      % dirs /home/john /home/mary /home/doggie /home/witherspoon % pushd +2 /home/doggie % dirs /home/doggie /home/witherspoon /home/john /home/mary

      Note that both before and after the pushd, /home/john precedes /home/mary, and /home/doggie precedes /home/witherspoon. The example also shows that, for the purpose of the pushd +n command form, /home/witherspoon (the last entry) is effectively followed by /home/john (the first entry).

      Returning to a Previous Directory Using the Directory Stack—popd

      After you have saved directories on the directory stack with pushd, you can use popd to return to a previous directory. The syntax for the popd command is as follows:

      popd [ +n ]

      The following example shows the use of pushd, dirs, and popd together:

      % pwd /usr/home/john % pushd /usr/spool % pushd uucppublic % pushd receive % dirs /usr/spool/uucppublic/receive /usr/spool/uucppublic /usr/spool _/usr/home/john % popd /usr/spool/uucppublic % dirs /usr/spool/uucppublic /usr/spool /usr/home/john % popd /usr/spool % dirs /usr/spool /usr/home/john % popd /usr/home/john % dirs /usr/home/john

      Used in the form popd +n, the command deletes the nth entry in the stack. Stack entries are numbered from 0, which is your current directory.

      Changing the Active Shell

      The C shell provides a number of commands for changing the active shell. Although your login shell may be the C shell, you are not limited to it; you can change your shell to Bourne shell or the Korn shell at any time using the exec command. The exit and logout commands also change the active shell, by returning you to the shell that was active before your current shell: issued from your login shell, they return you to the login screen, which is itself a kind of shell (of somewhat limited functionality).

      Other commands, such as umask and nohup, change the manner in which UNIX treats the shell.

      In order to make the best use of the information in this section, you should also read Part IV, Process Control, later in this guide, which describes some of the UNIX mechanisms these commands are designed to manipulate.

      Invoking a New Shell—exec

      The exec command transfers control to the specified command, replacing the current shell. The command you specify becomes your new current shell. The syntax of the exec command is as follows:

      exec command

      Nearly always, command should be a shell invocation command such as csh, sh, or ksh. Control cannot be returned to the invoking environment because it is replaced by the new environment. Shell variables exported with the setenv command will be passed to the new shell in the usual manner; all other command contexts, including local variables and aliases, will be lost.

      The exec command is equivalent to the Bourne shell exec.

      Exiting from the Current Shell—exit

      The exit command causes the current shell invocation to be exited. Its syntax is as follows:

      exit [ (exp) ]

      If issued from within a shell script, the shell script is terminated and control returns to the invoking shell. If issued from your login shell, the .logout script in your home directory will be executed before the shell exits. Normally, the UNIX operating system will redisplay a login screen after an exit from the login shell.

      If you provide the optional exp argument (which must be enclosed in parentheses), the argument is evaluated as an arithmetic expression, and the resulting value is used as the shell's exit code; otherwise, the current value of the status variable is taken as the shell's exit code. The status variable is described in the section "Using Predefined Variables" later in this chapter.

      Invoking the System Login Procedure—login

      Use the login command to log out from your current shell and to immediately log in under the same or a different user ID. Its syntax is as follows:

      login name [ arg ... ]

      Using this shell built-in command is not quite equivalent to logging out in the normal manner and then logging in. If you use the login command from a remote terminal, the line connection will not be dropped, whereas logging out in the normal manner drops the line and requires you to re-establish the connection before you can log in again.

      You cannot execute the login built-in command from a subshell; it is legal only for your login shell.

      For name, specify the user name you want to log in with. Any arguments you specify after name are passed to the /bin/login command and are defined by /bin/login, not by the shell.

      Exiting from a Login Shell—logout

      Use the logout command to log out from your login shell.


      You can also terminate the login shell (or any subshell) with the exit command. If you have the ignoreeof option set, you cannot use the EOF key to exit from the shell; in such a case, use logout or exit. See the section "Using Predefined Variables" for a definition of the ignoreeof option.

      Preventing a Command from Terminating Execution after Logout—nohup

      Use the nohup command to run a command that is insensitive to the Hangup signal.

      nohup [ command ]

      The UNIX operating system always sends a Hangup signal (signal 1) to a process when its process group leader logs out. The net effect is that normally any command you are running when you log out is terminated. (Although you can't ordinarily issue the logout or exit command, or enter an EOF character, while you are running a command, you can always force a logout by turning off your terminal, or if using a remote terminal connection, by hanging up the line.)

      When you invoke a command with nohup, the shell effectively disables the Hangup signal so that the command cannot receive it, thus allowing command to continue to execute after you log out.

      You can disable the Hangup signal for your interactive shell or from within a shell script using the trap built-in command, and binary programs written in the C language can also disable or ignore the Hangup signal. However, not all commands do this. If you use nohup to invoke the command, you are assured that the Hangup signal will be ignored whether or not the command disables the signal.

      Use nohup with no arguments from within a shell script to disable the Hangup signal for the duration of the script.

      Use nohup command to run command with the signal disabled.

      Displaying and Setting the Process File Creation Mask—umask

      The process file creation mask (sometimes, for purposes of brevity, called the umask), is an attribute of the shell process, just like the current directory is a process attribute. The purpose of the file creation mask is to specify the default permissions assigned to new files you create, for example when redirecting the output of a command to a file with the > operator. It would be extremely inconvenient if the system prompted you for file permissions every time it created a file, especially since most of the time you would assign the same permissions to all new files.

      If you're not familiar with file permissions, you may want to review the section "File Security" in Chapter 3, "The UNIX File System." Briefly, file permissions are little flags that UNIX associates which each file. The flags indicate whether the file can be read, written, or executed, and by whom.

      The file creation mask is a device you use for indicating what permissions UNIX is to assign to a new file by default. If you want some other access permissions for a file, the usual approach is to first create the file, then change the file's permissions with the chmod command.

      The file creation mask itself is a binary value consisting of nine bits, corresponding to each of the permission bits for a file. As a matter of convention, the nine bits are represented by three octal digits, with each digit representing three bits. The file creation mask is therefore a value expressed in octal as three octal digits. The use of octal number representation for the file creation mask is a matter of convention, not necessity, yet the umask command does not allow you to use any other number form for displaying or setting the file creation mask: you must use octal to set the mask, and you must interpret octal values to understand the mask when displayed.

      As for the mask itself, each of the bits in the mask indicate whether the corresponding bit of the file permission should be set off, (set to zero). By default, virtually all UNIX commands attempt to set all reasonable permission bits to one when creating the file. A command that creates a data file (such as a text file), tries to create the file with permissions of 666. In octal, this would grant read and write permission to you the file's owner, to other members of your UNIX group, and to all other system users; it would however leave the execute permission unset. Commands which create executable files (such as cc and ld) attempt to set the file's permissions to 777, which in octal would set the read, write, and execute bits for all users.

      Because of this default action by UNIX commands, it is the function of the file creation mask to specify permissions you don't want set. When you set a bit in the file creation mask, it causes the corresponding bit of the file's permissions to be forced to zero. Bits not set in the file creation mask are interpreted as don't care: the file permission bit stays unchanged.

      Now, the bits of the file permissions, from left to write, are written rwxrwxrwx, where the first three bits represent read, write, and execute permissions for the file's owner; the second set of three bits represent read, write, and execute permissions for the file's group; and the third set of three bits are the permissions for other users. To grant read and write permissions to the file's owner, but only read access to other users, the appropriate file permissions setting would be the bits 110100100. Writing this in octal, you arrive at the familiar permissions value of 644, which you may already have seen in the output of the ls command.

      Remember that UNIX commands try to create files with all reasonable permissions set. For a data file, these bits are 110110110, corresponding to rw-rw-rw-. To get the permissions switched to rw-r—r—, you need to set off the fifth and eight bits. A file creation mask of 000010010 (in octal 022) would do the trick. When the file is created, UNIX lines up the bits in the file permissions requested by the command, and your file creation mask, like this:

      1 1 0 1 1 0 1 1 0 attempted file permissions 0 0 0 0 1 0 0 1 0 file creation mask ———————— 1 1 0 1 0 0 1 0 0 actual file permissions

      What you have to do when using the umask command, therefore, is first to decide what file permissions you would like assigned to your new files by default, and then write a bit mask as an octal number which sets the appropriate file permission bits to zero.

      As it happens, most UNIX users want to reserve write permission for their files to themselves, but are willing to let other people look at the files. The appropriate file creation mask for this is 022 in octal. In many cases, the system administrator sets up the system so that the umask 022 command is automatically executed for you when you login in. If the administrator has not set up a default, or you wish to use another file creation mask, you can set a new mask in your login profile.

      The actual syntax of the umask command is straightforward:

      To display the current process file creation mask, use the umask command as follows:

      % umask 022

      You can also use umask to set the process file creation mask by specifying the octal argument as follows:

      % umask octal

      The process file creation mask is set to the bit pattern corresponding to the low-order nine bits of the octal number octal.

      Echoing Arguments to Standard Output

      C shell provides two commands for echoing arguments to standard output: echo and glob. The only difference between them is the delimiter used to separate words in the output line.

      The echo command, though most often used when writing shell scripts, also comes in handy in a number of keyboard situations, for example when constructing a pipe to a non-interactive command. One of the best examples of the echo command is using it to display the value of a shell variable:

      % echo $path /usr/bin /usr/ucb/bin /usr/local/bin /home/jjv/bin %

      In this case, it is the variable substitution expression $path which does the real work; the echo command provides only the step of printing the value on the terminal. Nonetheless, without the echo command it would be cumbersome to check the value of a variable: the set command will also print variable variables, but it prints all variables, sometimes producing a lengthy list that takes time to search for the entry you want.

      The glob command, on the other hand is rarely used in any context. It was originally intended to be called from a C program (not a shell script), to get the shell to expand a filename wildcard expression. However, most C programmers don't use this technique because it relies on the existence of the C shell.

      Using the echo Command

      The echo command prints a line containing its arguments to standard output. The syntax for the command is as follows:

      echo [ -n ] wordlist

      The arguments are printed with one intervening blank between them and a newline character after the last one. The echo command does not modify the words in wordlist in any way, but the arguments as seen by echo might differ from those on the original command because of variable, command, and history replacement and filename globbing. For example, the following command

      echo Directory $dir contains these files: *.c

      might generate the following line to standard output:

      Directory /usr/lib1 contains these files: myprog.c bigprog.c

      Specify option -n to suppress printing a newline character; this allows the next input or output to occur on the same line as the output of the echo command.

      Using the glob Command

      The glob command also prints a line containing its arguments to standard output. The syntax for the command is as follows:

      glob [ wordlist ]

      Use glob to print the words in wordlist to standard output. The words are printed with a null character between each (not white space as echo does). The last word is followed by a newline character.

      The words in wordlist are subject to variable, command, and history substitution and filename expansion in the usual manner. After scanning for substitutions, the resulting strings are redivided into words, which are then written using the null character delimiter.

      The glob command is similar to echo, differing only in the delimiter used to separate words in the output line. Because most terminals cannot print a null character, glob is not normally used to generate terminal output. It is intended to be called from a C language program, in the form /bin/csh -c 'glob ...', to invoke the shell substitution and filename expansion mechanisms.

      Rescanning a Line for Substitutions—eval

      Use eval to rescan the arguments arg for variable, command, and history substitutions, filename expansion and quote removal, and then execute the resulting words as a command.

      eval arg ...

      With eval, you can essentially write shell script lines with a shell script and execute the resulting generated commands. Remember, however, that to embed variable symbols in a string, you must hide the leading dollar sign from earlier shell substitutions.

      The eval command implemented by the C shell is equivalent to the Bourne shell eval command.

      Changing Your Group ID—newgrp

      The newgrp command is the same as the UNIX newgrp command:

      newgrp groupname

      When issued from your login shell (not to be confused with a login shell script, the login shell is simply that shell started up for you automatically when you log in), newgrp causes the current shell to be replaced by a new shell with the real and effective group IDs both changed to the specified group groupname. Because the shell is replaced, all context, including exported variables and aliases, is lost.

      Use the newgrp command when you have been authorized by the system administrator for membership in two or more user groups, and you wish to change your group identification from your current or login group to another group. Your group identification is used by the system when determining whether to grant you access to files.

      Timing the Execution of a Command—time

      Use time with no argument to display the amount of CPU time in seconds used by the current shell and all commands and subshells invoked since its start. This form of the command is usually of interest only to folks who are being billed for the amount of machine time they use, as might be the case if you are renting time on a commercial machine. By entering the command with no arguments occasionally, you can monitor how much machine time you have used and limit your online time accordingly.

      time [ command ]

      Only for your login shell will this be the amount of machine time used since you logged- in. Also, note that this is not elapsed wall clock time—it is only machine time used.

      Use the form time command to execute command and report the amount of CPU time used by the command's execution. The command must be a simple command, not a compound command, statement group, or parenthesized statement, and cannot be a pipeline.

      You might be interested in timing the execution of a command if you are a production operations manager and you want to find out how much time a new application is adding to your daily workload. A development programmer would use the time command to determine whether a new program has a performance problem. The average interactive user, however, would have infrequent occasion to use the time command.


      One of the handier features of the C shell is the alias feature. An alias is a shorthand method of referring to a command or a part of a command. For example, if you have several favorite options that you always supply to the ls command, rather than having to type the whole command every time, you can create a two-character alias. Then you can type the two-character alias, and the shell will execute its definition.

      An alias can represent not only a command name, but also leading options and arguments of the command line. Any words you type following the alias name are considered to follow options and arguments included in the alias definition, allowing you to customize the command with key options and arguments.

      More complex processing can be achieved using shell scripts, where the function performed by the shell script file's name used as a command can be arbitrarily complex. The command alias feature was provided only for use as a keyboard shortcut, and anything that can be achieved using an alias can be done with shell scripts.

      You should add command aliases that you use often to your .login file, so that the alias will be defined every time you log in. It is often handy, however, to define command aliases at the keyboard for special commands you'll be using during this session. Unless you incorporate the alias into your .login file, it will be lost when you log out.

      Defining, Listing, and Changing Command Aliases—alias

      The alias command allows you to list currently defined aliases, to define a new command alias, or to change an existing alias. The command format is

      alias [ name [ definition ... ]]

      For name, choose a word consisting of upper- and lowercase letters and digits. For definition, write any sequence of words that defines the command string you want name to stand for. For example, the following defines two aliases for the ls command, each providing a different set of options. It's shorter to type the alias name for the particular style of ls command output than it is to type the ls command and options.

      alias lx /usr/bin/ls -FC alias ll /usr/bin/ls -l

      If you want to change the definition of an alias, you simply define it again.

      Once you have defined aliases, you can display a list of their names and definitions by entering the alias command without arguments, as in the following example:

      % alias alias lx /usr/bin/ls -FC alias ll /usr/bin/ls -l

      You can also display the definition of a specific alias by specifying its name as an argument:

      % alias lx alias lx /usr/bin/ls -FC

      Alias substitution occurs early in the shell's processing cycle for commands, thereby allowing you to use globbing (filename replacement), variable substitution, command substitution, and command history substitution in the wordlist. Because of this, you will often need to quote at least one of the words of definition, and perhaps the entire alias definition. Some people always enclose the alias definition in quotes to avoid surprises. Consider the following alias:

      alias lc ls *.[ch]

      For a C language programmer, the alias would be rather natural: by simply typing lc, you get a listing of all source program files in the current directory, devoid of any other file clutter.

      NOTE: Note that substitutions will occur when the alias command is processed, unless you quote all or part of the wordlist.

      However, the preceding alias definition will not work as expected. The filename pattern *.[ch] will be substituted on the alias command itself, and the actual alias stored (depending on the actual directory contents when you enter the alias command) will be as you see here:

      % alias lc ls app.h io.c main.c prog.c sundry.h

      Because the filename pattern was replaced before the alias definition was stored by the shell, the lc alias won't list all files ending in .c or .h; it will attempt to list the files app.h, io.c, main.c, prog.c, and sundry.h whether they exist in the current directory or not.

      The alias should have been defined as follows:

      % alias lc ls '*.c'

      An alias definition can also use command aliases. During alias substitution, the alias definition is scanned repeatedly until no further substitutions can be made. An alias definition for name, however, cannot invoke the name alias within itself; a reference to name in the wordlist will be taken as a reference to the shell built-in command or executable file named name, not as a reference to the alias. This allows you to use an alias to redefine a system command or shell built-in command, for example:

      % alias pg pg -cns -p"Page %d:"

      You can refer to arguments of the original command line, before any substitutions were made, using the command history substitution syntax (see the section later in this chapter titled "Command History"). For example, the command

      alias print 'pr \!* | lp'

      defines an alias named print that executes the pr command using all the arguments of the original command line (\!*), then pipes the output to lp for printing.

      To properly understand and use the alias command, you must be clear about the way an alias is used. When you define an alias by entering the alias command, the only thing that happens at that time is that the system stores the alias in computer memory. Later, when you enter a command with the same name as the alias, the C shell does a little magic. The command you typed will not be executed in the form you typed it. Rather, the command name (which is an alias name) will be replaced by the value of the alias. The result is a new command text, the front part of which is the alias definition, and which ends with any other arguments you typed.

      For example, suppose you define an alias for the ls command as follows:

      % alias lax ls -ax

      If at some later time you enter this command:

      % lax big*.txt

      the command actually executed will be:

      ls -ax big*.txt

      The command alias (lax) is replaced by its definition (ls -ax). Remaining arguments on the command line (big*.txt) are simply tacked on after the alias substitution, to yield the command the computer will actually execute.

      Using history substitutions in an alias provides additional flexibility, namely by allowing the executed command to employ arguments in a different order or a different form than entered, but require a little extra work from the shell. Consider the following alias definition:

      alias lsp 'ls \!* | lp'

      Entering the command lsp *.c *.sh will result in alias substitution for lsp. The symbol !* will cause the arguments you entered on the line *.c *.sh to be inserted into the alias definition, rather than tacked on after. In other words, if an alias definition contains a history substitution, the shell suspends its normal action of tacking on command arguments after the alias value. The command actually executed will be ls *.c *.sh | lp. Without this special mechanism, the executed command would have been ls *.c *.sh | lp *.c *.sh, with the final *.c *.sh being tacked on in the usual manner, leading to an undesirable result: instead of printing a directory listing, the lp command would print the full contents of the files.

      When writing an alias, you therefore need to visualize what will happen when the alias is substituted in later commands.

      Deleting a Command Alias—unalias

      Use unalias to delete one or more aliases. You can delete a specific alias by specifying its name as an argument, or you can delete multiple aliases by using pattern-matching:

      unalias name unalias pattern

      If you specify a specific alias name, only that alias definition is deleted. If you specify a pattern, all those currently defined aliases whose names match the pattern are deleted. pattern can contain the pattern-matching characters *, ?, and [...]. In the following example, the first line deletes the lx alias, and the second line deletes all currently defined aliases:

      unalias lx unalias *

      Shell Options

      The C shell supports a number of command-line options to support special uses of the shell. These options are shown in Table 13.3.

        Table 13.3. C shell options.


      The shell executes the commands in the first argument string, then exits. Called from a C language program in the form csh -c "commands" to execute a shell command or list of commands (separated with semicolons or newline characters).


      If set, causes immediate termination of the shell if a command returns a nonzero exit code. This option is mainly used in shell scripts to abandon processing if a command sequence fails; it is simpler to use than individually checking the exit code of each command.


      If set, suppresses reading of the .cshrc initialization script. Use this option to speed up shell initialization and shell script execution. (See "Customizing Your Shell Environment" later in this chapter for more information about the .cshrc file.)


      Forces the shell to use interactive mode, even if its input is not a terminal. In interactive mode, the shell writes prompts to the standard error file prior to reading each command and ignores the Intr and Quit signals. The -i option is assumed when the shell is started with terminal input and output.


      If set, suppresses execution of commands. Command interpretation still occurs. Use the -n option to discover whether the shell script contains any syntax errors without actually executing commands it may contain.


      If set, prevents interpretation of the first command-line argument of csh as a shell script filename. Used when you are executing a stream of commands from standard input and you wish to set one or more argv arguments on the shell command line—for example, csh -s /usr/bin < file. Command-line arguments can be referenced by the commands in file.


      Forces the shell to terminate after reading and executing one line from standard input. If the command must be continued onto more lines, append \ to all lines but the last. The shell does not buffer up input when this option is set; it can therefore be used to read and execute the next line from a currently open file.


      Sets the verbose variable. The verbose variable causes the shell to echo commands to the terminal before any substitutions are made and before the commands' execution. Sometimes used to assist with debugging a shell script, in the form csh -v filename.


      Sets the echo variable. Commands are echoed to the terminal after substitution and filename generation but before execution. Sometimes used to assist with debugging a shell script, in the form csh -x filename.


      Like -v but sets the verbose option before processing the .cshrc initialization script. Use this option to display lines from the .cshrc script as they are executed.


      Like -x but sets the echo option before processing the .cshrc initialization script.

      Unless one of the -c, -i, -s, or -t options is set, the shell construes the first command-line argument as the name of a file to be executed. Remaining command-line arguments are assigned to the $1, $2, _ variables, and to the argv array variable. The -c option allows only one command-line argument and takes it as a list of commands to be executed; after execution of the argument string, csh exits. When the -i, -s, or -t option is set, the shell assigns all arguments including the first to the $1, $2,_variables and the argv array variable.

      The shell supports additional options that you can switch on or off during shell operation. These options are controlled by variables; if the variable is set, the corresponding option is activated; if it is not, the option is off. These options are described in the section titled "Using Predefined Variables" later in this chapter. Briefly, their names are echo, ignoreeof, noclobber, noglob, nonomatch, notify, and verbose.

      Additionally, the shell variables cdpath, history, mail, path, prompt, and shell, although not options as such, allow you to control certain shell behaviors such as searching for commands and checking for mail. See the section titled "Using Predefined Variables" for further information.

      Command History

      The shell's command history service maintains a list of previously executed commands. You can use command history for two purposes: as a reference to determine what you've already done, and, with history substitution, as a shorthand method to reuse all or part of a previous command in entering a new command.

      Displaying the Command History

      The history command enables you to print all or selected lines of the current command history.

      history [ -r ] [ n ]

      To display all the lines currently held in the history list, enter the history command (it takes no arguments):

      % history 1 cd src 2 ls 3 vi foo.c 4 cc foo.c 5 grep '#include' foo.c

      The shell displays each line preceded with a line number. You can use the line number to refer to commands with the history substitution mechanism. Line numbers start with 1 at the beginning of your session.

      The amount of history a shell maintains is dependent on the amount of memory available to the shell. History is not saved in an external disk file, so capacity is somewhat limited. You can set the history variable to a value indicating the number of lines of history you want the shell to maintain; it will keep that number of lines and more if possible, but your specification is only advisory. The value of history must be a simple number to be effective. For example, set history=25 retains at least twenty-five lines of history.

      CAUTION: The history service retains command lines, not commands. As the history area becomes full, the shell discards old lines. This might result in some lines containing incomplete, partial commands. You need to use caution with the history substitution facility to avoid calling for the execution of an incomplete command.

      To limit the number of lines displayed, specify an integer decimal for n to limit the number of lines displayed to the last n lines of history.

      Specify the -r option to print history lines in reverse order, from the most recent to the oldest.

      Using History Substitutions to Execute Commands

      History substitutions are introduced into a command with the ! (exclamation point, sometimes called the bang operator). You append one or more characters to ! to define the particular kind of history substitution you want. If followed by a blank, tab, newline, equal sign (=), or open parenthesis (, the exclamation point is treated as an ordinary character.

      NOTE: The exclamation point is an ordinary character to other shells, but it is special to the C shell: you must precede it with \ (backslash) to avoid its special meaning, even inside quoted strings. The shell will attempt a history substitution wherever it finds an exclamation point in the command line, without regard to any quoting; only the backslash can avoid interpretation of ! as a history substitution mark.

      You can write a history substitution anywhere in the current shell input line, as part or all of the command. When you enter a command containing one or more history substitutions, the shell echoes the command after performing the substitutions so that you can see the command that will actually be executed. (You do not have an opportunity to correct the command; it is executed immediately after being displayed.)

      The simplest forms of history substitution are !! and !number. The !! symbol is replaced with the entire previous command line. The expression !number is replaced with line number from the command history list.

      Suppose command history currently contains the following lines:

      % history 1 cd src 2 ls 3 vi foo.c 4 cc foo.c 5 grep '#include' foo.c

      If you now enter the command !!, the shell will repeat the grep command in its entirety. Press return to execute the grep command, or type additional words to add to the end of the grep command:

      % !! sna.h grep '#include' foo.c sna.h

      Continuing the example, suppose after running grep you want to edit the foo.c file again. You could type the vi command as usual, but it already appears in command history as line 3. A history substitution provides a handy shortcut:

      % !3 vi foo.c

      That's almost all there is to basic history substitution. Actually, the shell supports any of the following forms for referring to command history lines:


      Replaced with the previous command line (the last line of command history).


      Replaced with line number of command history.


      Replaced with the history line number lines back; !-1 is equivalent to !!.


      Replaced with the most recent history line having a command that begins with string. For example, use !v to refer to a previous vi command.


      Replaced with the most recent history line containing string anywhere in the line. For example, use !?foo? to repeat a previous vi foo.c command.

      You can do more with history substitutions than merely reuse a previous command. The shell also provides extensions to the history operator that allow you to select individual words or a group of words from a history line, inserting the selected word or words into the current command. These extensions are in the form of a suffix beginning with : (colon). For example, !vi:1 is replaced not with the most recent vi command, but rather with its first argument word. Similarly, !3:3-4 is replaced with arguments 3 and 4 of history line 3. You can use any of the following expressions as word selectors by appending the expression to a line reference, preceded with a colon:


      First word of the command (usually the command name).


      nth argument of the command. Arguments are numbered from 1. Note that 0 refers to the command name, which is actually the first word of the line, whereas 1 refers to the second word of the line.


      Same as :1, the first argument.


      Last argument word of the command.


      For the !?string? format, the word matched by string. Use this word selector only with the !?string? history reference. Its value is the entire word matching string, even though string might have matched only a part of the word.


      Multiple word substitution. Replaced with words m through n of the history line. For m and n, specify an integer number, or one of the special symbols ^, $, or %.


      Substitutes words beginning with the mth word and extending up to but not including the last word.


      Same as 0-n; substitutes words beginning with the first word of the history line (the command name) through the nth word.


      Same as m-$; substitutes words beginning with the mth word and extending through the last word of the line.


      Same as ^-$; substitutes all argument words of the line.

      If the word selector expression you want to write begins with ^, $, *, -, or %, you can omit the colon between the line selector and the word selector. For example, !vi* refers to all the arguments of the previous vi command, and is the same as !vi:* or !vi:^-$.

      You can use any number of word selectors in the same command line. By combining multiple word selectors, you can reuse arguments of a previous command in a different order and use arguments originally appearing on different commands. For example, the command rm !115^ !117^ removes files that were named on two earlier commands.

      When counting words of a previous command line, the shell takes quoting into consideration but uses the line as it appears in the history list; words generated by variable or command substitution or filename generation are not accessible.

      You can append modifiers to a word selector to alter the form of the word before insertion in the new command. A modifier is written in the form :x, where x is a letter specifying how the word should be modified. For example, !vi^:t will substitute the tail of the first argument of the vi command: for the argument /usr/X/lib/samples/xclock.c, the value of :t will be xclock.c.

      The following modifiers can be appended to a word selector to alter the selected word before substitution:


      Removes a trailing path component. Successive :h modifiers remove path components one at a time, right to left. Thus for the argument /usr/X/lib/samples/xclock.c, :h will return /usr/X/lib/samples, whereas :h:h will return /usr/X/lib.


      Removes a filename suffix of the form .string. For example, for the argument foo.c, :r will return foo.


      Removes all but the filename suffix. For the argument foo.sh, :e will return .sh.


      Removes all leading components of a path, returning just the filename part. For the word /usr/bin/ls, the value of :t is ls.


      Replaces the string x in the selected word with the string y. String x cannot be a regular expression. The symbol & appearing in y is replaced with the search string x, thus :s/bill/&et/ will substitute billet for bill. Any character can be used in place of the slash, for example :s?/usr?/user?. The final / can be omitted if followed by a newline. The delimiter (/ or your delimiter) or & can be used as a text character by escaping it with \ (backslash), for example :s/\/usr/\/user/. The search string x can be omitted, in which case the search string of the previous :s on the same line is used, or if no previous :s occurred, the string of !?string? is used.


      Reuses the previous string substitution modifier :s appearing in the same command line, thus !grep:2:s/bill/marty/ !:3:& is the same as !grep:2:s/bill/marty/ !3:s/bill/marty/.


      Used in any history substitution expression on the command line, causes the shell to print the command after substitutions, but not to execute it. Use :p to try the effect of a history substitution before executing it.


      Encloses the substituted word or words in quotes to prevent further substitutions.


      Breaks the selected word or words at blanks, tabs, and newlines.

      Normally, a modifier affects only the first selected word. When selecting multiple words, such as with !12:2*, you can apply a modifier to all of the selected words by inserting a g in front of the modifier letter. For example, !12:2*:gh will apply the :h modifier to all of the words. The g is not valid with the :p, :q, and :x modifiers.

      You can omit the command identifier from a history substitution when using two or more ! expressions in the same line; successive history references then refer to the same command as the first. For example,

      % vi %grep^:t %:3:t %:4:t

      all refer to the same grep command but select the first, third, and fourth arguments.

      The history mechanism supports a special abbreviation ^ useful for correcting a keying error in the previous line. The general form of the abbreviation is ^x^y, where x and y are strings. The previous command line is selected and searched for string x; if found, it is replaced with y, then executed. For example, after the command cd /usr/ban, enter the line ^ban^bin (or ^an^in) to execute the command as cd /usr/bin. The caret ^ must be the first nonblank character of the line to be recognized as a line editing substitution. This abbreviation is available only for the immediately preceding command line; you must use the full history expression !line:s/x/y/ to edit any line other than the last.

      One final, important provision of the history substitution mechanism is that you can enclose any history reference in braces {} to isolate it from characters following it. Thus, !{vi^:h}.c forms a word beginning with the selected history reference and ending in .c.


      You can use shell variables to hold temporary values, and shell scripts can use variables to manage changeable information. The shell itself also has variables of its own that you can use to customize features of the shell and your shell environment.

      A variable is actually an area of the shell's memory set aside to hold a string of characters and given a name. You assign the name of a variable when you define it with set. You can change the value of a variable in several ways.

      The shell provides a complex set of syntax for referring to the value of a variable. Any variable reference, when scanned in a command line, is replaced by the corresponding value of the reference before the command is executed. In its simplest form, a variable reference simply replaces the name of a variable with its string value.

      This section looks at the kinds of variables the shell supports and the rules for naming them and referring to their value.

      Variable Names

      The shell imposes no set limit on the size of variable names. People commonly use variable names of six to eight characters, and names up to sixteen characters are not unusual.

      A variable name can consist of only uppercase and lowercase letters and digits. The name cannot begin with a digit, because names beginning with a digit are reserved for use by the shell. General usage indicates the use of all capital letters for the names of environment variables, and all lowercase letters for local variables, although the shell imposes no such restriction.

      You assign a value to a variable using the set or setenv built-in commands, depending on the type of variable you are setting.

      NOTE: The C shell does not support the assignment statement name=value, which might be familiar to you from the Bourne and Korn shells.

      Creating Shell Variables

      Use the set statement to create new local variables and optionally to assign a value to them. Local variables are known only to the current shell and are not passed to shell scripts or invoked commands.

      Use the setenv statement to create new environment variables. Environment variables are passed to shell scripts and invoked commands, which can reference the variables without first defining them (no setenv statement is required or should be used in a shell script for passed environment variables you wish to access). (See the section "Displaying and Setting Global Environment Variables" below for more about environment variables.)

      A shell variable can contain any characters, including unprintable characters, as part of its value. A shell variable can also have a null value, which is a zero-length string containing no characters. A variable with a null value differs from an unset variable: a reference to the former has the effect of merely deleting the variable reference, because it is replaced with a zero-length string; a reference to an unset variable is an error, generates an error message, and causes the shell interpretation of commands to stop.

      Displaying and Setting Local Shell Variables—set

      The set command can be used to display or set local variables.

      set set name=word set name=(wordlist) set name[index]=word

      Use set with no arguments to list the currently defined variables and their respective values. The listing includes exported variables as well as local variables.

      Any of the operand formats can be combined on a single set statement; each assigns a value to a single shell variable or element of an array variable. Note that no white space should separate the variable name, equal sign, or value when writing an assignment; any white space appearing in word or wordlist must be hidden with quotes.

      Use set name to define a variable name and to initialize it with a null string. This form can be used to set a number of shell options (such as set ignoreeof). A variable with a null value is not the same as an unset variable; the former exists but has no value, whereas the latter does not exist. A reference to an unset variable results in a shell error message; a reference to a null variable results in substitution of the null string.

      Use set name=word to assign the string word as the current value of variable name. The string replaces the current value of name if the variable is already defined; otherwise, a new variable named name is created. If word contains characters special to the shell (including blanks or tabs), it must be enclosed in single or double quotes.

      Use the form set name=(wordlist) to assign each word in wordlist to successive elements of the array variable name. After the assignment, the expression $name[1] refers to the first word in wordlist, $name[2] to the second word, and so on. Any word in wordlist must be quoted if it contains characters special to the shell (including blanks or tabs).

      Use the form set name[i]=word to assign the string word as the current value of the ith element of the array variable name. For i, specify a decimal integer number not less than 1. Note that you do not have to assign a value to every element of an array. The number of elements in an array is effectively the highest-numbered element to which a value has been assigned. Elements to which no value has been assigned have an effective value of the null (zero-length) string. Also note that you cannot assign a (wordlist) to an array element; an array variable can have multiple values, but each element can represent only one string value.

      Deleting Local Shell Variables—unset

      Use the unset command to delete one or more shell variables from the shell's memory.

      unset pattern

      The unset command is effective for variables defined with the set command only; use the unsetenv command to delete variables defined with setenv.

      For pattern, specify a string that might optionally contain one or more occurrences of the pattern-matching characters *, ?, or [...]. All local variables known to the shell whose names match the specified pattern are deleted. You will receive no warning message if nothing matches pattern, and no confirmation documenting the variables that were deleted.

      Displaying and Setting Global Environment Variables—setenv

      Use the setenv statement to create new environment variables. Environment variables are passed to shell scripts and invoked commands, which can reference the variables without first defining them (no setenv statement is required or should be used in a shell script for passed environment variables you wish to access). See the section later in this chapter titled "Customizing Your Shell Environment" for more about environment variables.

      The format of the setenv command is: setenv [name=value ...]. Issued without arguments, the setenv command lists all global environment variables currently in effect, together with their values. Used in the form setenv name=value , the shell creates a new global variable with the specified name and assigns the string value as its initial value. If the value contains contains characters such as the space or tab, be sure to enclose the value string in quotes. (See the section "Quoting and Escaping Special Characters" in this chapter for information about shell special characters and the use of quoting techniques.)

      UNIX also provides a command (env) for displaying the current list of environment variables and their values. The env command actually supports a number of options and arguments for modifying the current environment.

      The section "Using Predefined Variables" below provides a list of all variables (local and environment) which are defined by the C shell. Environment variables defined by other UNIX components are defined in the documentation for those components. Unfortunately there is no comprehensive list of environment variables, because some are defined by non-shell programs. The mailx command, for example, defines some variables, and the vi command looks for some variables of its own. Altogether the environment variable pool is optional anyway: if you don't know of a variable some UNIX command uses, the command will still work without it. At any rate, be aware that the shell is not responsible for defining all environment variables; it merely provides a means for manipulating and accessing them.

      Deleting Global Environment Variables—unsetenv

      To delete global environment variables, you use the unsetenv command:

      unsetenv variablename unsetenv pattern

      Use the unsetenv command to delete one or more environment variables from the shell's memory. The unsetenv command is effective only for variables defined with the setenv command; use the unset command to delete variables defined with set.

      To delete a particular variable definition, specify its name as variablename. To delete multiple variable definitions, use pattern to specify a string that might optionally contain one or more occurrences of the pattern-matching characters *, ?, or [...]. All environment variables known to the shell whose names match the specified pattern are deleted. You will receive no warning message if nothing matches pattern, and no confirmation documenting the variables that were deleted.

      Obtaining Variable Values with Reference Expressions

      You obtain the value of a shell variable by writing a variable reference on the command line. A variable reference results in replacement of the entire reference expression, including the $ that introduces the reference, the variable's name, and any other characters that might adorn the reference, with a string value of the reference.

      A variable reference does not itself define the start or end of a word: the reference can be a complete word or a part of a word. If a part of a word, the substituted string is combined with other characters in the word to yield the substituted word. However, if the reference value substitutes one or more blanks or tabs into the word, the word will be split into two or more words unless it is quoted. For example, if the value of var is "two words," then the reference expression $var will appear as two words after substitution, but the quoted string "$var" will appear as the one word "two words" afterward.

      A variable reference can result in the substitution of the value of either a local or a global variable: a local variable is used if it exists, otherwise the value of an environment variable is taken. Remember, a variable reference refers to a variable by name: local and environment variables cannot have the same name, so a reference is to whatever variable has the specified name.

      You can use any of the variable reference forms shown in Table 13.4 in a word.

        Table 13.4. Shell variable references.


      Replaced with the value of name. It is an error if the ${name} variable name is not defined.


      Replaced with the value of elements of array variable ${name[n]}name. For n, write an element number, or a range of element numbers in the form m-n. Use -n to substitute elements 1-n, and m- to substitute elements m through the end of the array.


      Replaced with the number of elements in array variable ${#name}name.


      Replaced with 1 if variable name is set, otherwise 0. ${?name}

      The reference forms using braces (for example, ${name} and ${#name}) are useful when the variable name would run onto the remainder of the current word, yielding an undefined variable name. For example, if the variable dir contains the path prefix /usr/bin/, then the word ${dir}name.c will form the full pathname /usr/bin/name.c upon expansion; however, the simpler form $dirname.c would be taken as a reference to variable dirname, not at all what was intended. In effect, the braces set off the variable reference from the remainder of the word.

      A reference to an unset variable generates a shell error message and, if the reference occurs inside a shell script, causes reading of the shell script to terminate. You can use the $?name or ${?name} forms to handle the case where a variable might not be set. For example:

      if ($?nfiles) echo "File count is $nfiles"

      Using Array Variables

      Unless you provide otherwise, a variable can have only one value. An array variable, on the other hand, can have any number of values (provided only that the shell has sufficient memory available to store the values). For example, the path variable, used by the shell as a list of directories to search for commands, is an array variable where each element is a directory path.

      You assign values to an array variable in one of two ways—all at once, or one at a time. To assign many values at once, use a wordlist argument to the set command. A wordlist is a parenthesized list of words. For example, the following array contains four values:

      set path=(/bin /usr/bin $home/bin .)

      Each of the words in a wordlist is assigned to the next available element of the array variable. Assigning a wordlist to a variable automatically defines the variable as an array.

      To assign values individually to elements of an array, you must use array subscript notation. Written in the form name[index], the index must be a number designating an array element; elements are numbered starting with 1, so $name[1] is a reference to the first element of an array. The following example assigns three values to the array planets, then prints one of them using an array reference:

      % set planets[1]=Mercury % set planets[2]=Venus % set planets[3]=Earth % echo Planet 3 is $planet[3] Planet 3 is Earth

      If you reference the array variable name without an index, the shell replaces the reference with a wordlist:

      % echo The planets are $planets The planets are (Mercury Venus Earth)

      You can also use the reference $name[*] to obtain all the words of the array without the surrounding parentheses:

      % echo The planets are: $planets[*] The planets are: Mercury Venus Earth

      You can reference a specific range of elements using the notation $name[m-n], where m and n are the beginning and ending index numbers of the elements you want. For example, the following lists only the earth-like planets:

      % set planets=(Mercury Venus Earth Mars Jupiter Saturn Uranus Neptune Pluto) % echo The terraform planets are: $planets[2-4] The terraform planets are: Venus Earth Mars

      The special form $name[-n] refers to elements of the array beginning with the first and extending through n:

      % echo The inner planets are: $planets[-4] The inner planets are: Mercury Venus Earth Mars

      The special form $name[n-] refers to the elements of the array beginning with n and extending through the last:

      % echo The outer planets are: $planets[5-] The outer planets are: Jupiter Saturn Uranus Neptune Pluto

      One of the primary reasons for using array variables is to permit looping through the array, inspecting and manipulating each of its elements in turn. This programming technique, often used in shell scripts, can be used at the keyboard as well:

      % set files=(main io math dbase) % foreach file ($files) ? cp $file.c $file.bak ? end

      This example first assigns the root names of a list of files to an array variable, then uses the foreach shell statement to process each of the files in turn, by copying the file to a backup file, changing its filename in the process. (In the example, the question mark ? is the shell's prompt when it requires additional lines to complete an outstanding statement; it signals that you haven't finished the command yet.)

      Using Special Read-Only Variables

      In addition to ordinary variables that you define with the set and setenv commands, a number of variables are automatically defined by the shell and have preset values. Often the value of a special variable changes as the result of a command action. You can use these variables to acquire specific information that isn't available any other way. You cannot, however, use set or setenv to define these variables, and you can't assign new values to them.

      The special variables can be referenced using the notation shown in Table 13.5.

        Table 13.5. Shell special variables.


      Replaced with the name of the current shell input file, if known. If unknown, this variable is unset, and a reference to it is an error.


      Replaced with 1 if $0 is set, otherwise 0.

      $1, $2, ...

      Replaced with the value of the shell command's first (second, third,_) argument. If used within a shell script invoked by name, these symbols refer to the command $9 arguments. Up to nine arguments can be referenced this way. To reference arguments beyond nine, you must use the reference notation $argv[n].


      Equivalent to $argv[*]. Replaced with all the shell's arguments.


      Replaced with the process number of the parent shell. Used within a shell script, refers to the process number of the invoking shell.


      Replaced with a line of text read from the standard input file.

      The variables $1, $2, through $9 have special significance when used inside a shell script, because they refer to the arguments of the command line that invoked the shell script. The same command arguments are accessible via the array variable argv. Using the argv variable, you can refer to all command-line arguments, not just the first nine. For example, $argv[10] references the tenth argument, and $argv[$n] references whichever argument is designated by another variable $n.

      The shift built-in command can be used to manipulate command arguments. See the section titled "Shell Programming" for details about the shift command.

      Using Predefined Variables

      The C shell also recognizes a number of conventionally named variables as having special meaning. Some are automatically initialized when the shell starts; others you set yourself. You can assign a value to most of these variables, but some variables are set automatically by the shell when a corresponding event occurs.

      NOTE: Note that all predefined shell variables have lowercase names. This is to avoid conflicts with environment variables, which usually have uppercase names.

      To set any predefined variable, use the set command. You need to specify a value only if the variable requires one; otherwise you can omit the value string. For example, use set noclobber to enable the noclobber option, but use set prompt='$cwd: ' to assign a new command-line prompt string. (See the set built-in command in the section titled "Displaying and Setting Local Shell Variables—set" for more information about set.)

      You can use the unset built-in command to destroy the variable and any associated value, but be aware that an unset variable does not revert to its initial or default value and is not the same as a variable having a null value: an unset variable simply doesn't exist. (See the unset built-in command in the section titled "Deleting Local Shell Variables—unset" for more information about unset).

      The following list describes the variables to which the shell is sensitive and indicates any initialization or assignment restrictions.


      An array variable containing the current shell parameters. A reference to argv[1] is equivalent to $1, argv[2] to $2, and so on. The value of argv is set by the shell at startup and just prior to the execution of each command.


      An array variable specifying a list of directories to be searched by the cd command. The shell does not provide an initial value for cdpath. If you do not provide a value, the cd command searches only the current directory to resolve unanchored pathnames.


      Contains the full pathname of the current directory. On startup, the shell initializes cwd to the pathname of your home directory. Each cd command you execute changes the value of cwd.


      If set, the shell prints each command before execution. The echo variable is initialized to the null string if the -x option is present on the csh command line; otherwise the variable is left unset. You can activate command tracing at any time by executing the command set echo; to turn it off, use unset echo. Command tracing is effective only for the current shell invocation; it is not propagated into called shell scripts.


      Specifies the number of commands to be maintained in the history list. The shell will retain at least this many lines of command history if sufficient memory is available. The history variable is not initialized and does not need to be assigned a value. If unset, the shell maintains an optimum amount of command history for the size of available memory. You can set the value of history at any time.


      Initialized to the value of the HOME environment variable at shell startup. The value of home is used as the default directory for cd, and as the value substituted for ~. It is almost always improper for you to change the value of home, but you are not prevented from doing so.


      If set, the shell will ignore an end of file (EOF) character typed at the beginning of a line. If not set, an EOF character typed at the beginning of the line signals the shell to exit, which, for your login shell, also logs you out. The specific key corresponding to the EOF character can be displayed and changed using the stty (UNIX) command.


      An array variable listing the files to be monitored for change. If the first value is numeric, it specifies the frequency in seconds that the shell should check for new mail. If the last modification date of any one of the files is observed to change, the file issues the message New mail in name, where name is the name of the file that changed. (If mail lists only one file to be monitored, the notification message is You have new mail.) This command will monitor two mail files and specifies a give-minute interval for mail checking: set mail=(10 /usr/mail/jjv /usr/spool/mail/jjv).


      If set, the shell will not replace an existing file for the I/O redirection >. For >>, it will require that the target file already exists. You can activate the option with the command set noclobber, and turn it off with unset noclobber. When noclobber is set, you can use >! and >>! to perform the redirection anyway. The noclobber variable is initially unset.


      If set, filename expansion using the pattern characters *, ?, and [...] is disabled. The noglob variable is initially unset.


      If set, a filename pattern that matches no files will be passed through unchanged to the command. By default the shell issues an error message and ignores a command if no matching files can be found for a filename pattern argument. (Note that nonomatch is the default behavior of the Bourne shell.) Use set nonomatch to accept unmatched pattern arguments, and unset nonomatch to force a shell error message. The nonomatch variable is initially unset.


      If set, the shell writes a message to your terminal at once if the status of a background job changes. By default the shell does not notify you of status changes until just before issuing the next command-line prompt. Be aware that setting notify can cause messages to appear on your screen at inopportune times, such as when using a full-screen editor. The initial value of notify is unset.


      An array variable listing the directories to be searched for commands. If the path variable is not set, you must use full, explicit pathnames to execute non-built-in commands, even those in your current directory (./mycmd, etc). The initial value of path is the same as the PATH environment variable.

      The shell maintains a hash table of all the executable files in your search path. The hash table is initialized at startup time and is rebuilt whenever you change the value of path or PATH. Note, however, that if a new command is added to one of the files in your search path (including your current directory), the shell might not necessarily be aware of the addition and so might fail to find the command even though it exists. Similarly, removing an executable file from a directory early in your search path might not allow the execution of a like-named command in some other directory. In either of these cases, use the rehash built-in command to force rebuilding of the shell hash table.

      Other than the cases mentioned earlier, the shell hash table is invisible to you. It exists to speed up the search for commands by skipping directories where a command is known not to exist.


      Your prompt string. The value of prompt is printed at the start of each line when the shell is ready to read the next command. The value of prompt is scanned for variable and command substitutions before printing; history substitutions are allowed in the prompt string and refer to the command you last entered. The initial value of prompt is the string "% " (a percent sign followed by a blank) or, if you are the superuser, "# " (a pound sign followed by a blank).


      Because the C shell is capable of executing only shell scripts written in the C shell language, a mechanism is needed so that shell scripts written for the Bourne shell can be detected and passed to the proper program for execution. Any shell script where the first line begins with a nonexecutable command is considered to be a Bourne shell. To support this convention, Bourne shell scripts usually specify the : built-in command on the first line; there is no : command in the C shell. Similarly, scripts intended for the C shell usually begin with a command line and have the pound sign (#) in the first position.

      When the shell recognizes that a shell script has been invoked but is not a valid C shell script, the value of shell is used as the initial part of a command to execute the script. The value of shell is initialized to the full pathname of the C shell using a system-dependent directory prefix (usually /bin/csh). However, any number of options and arguments can be specified along with the shell pathname; the filename of the shell script will be appended to the value of shell.

      You should change the value of shell if you intend to execute Bourne shell scripts. (Note that many commands supplied with UNIX are implemented as Bourne shell scripts.)


      Contains the exit code of the last command executed, as a decimal number. The value of status is changed after the execution of each command, so it is normally useless for you to assign a value to status.


      If set, the value of time should specify a number of seconds. Any command you execute that exceeds this time limit will cause the shell to print a warning line giving the amount of time the command has used and the current CPU utilization level as a percentage. The initial value of time is unset.


      If set, causes each command to be printed after history substitutions but before other substitutions. The verbose option is normally used within a shell script to echo the commands that follow. The initial value of verbose is unset.

      Shell Programming

      Although the C shell provides a number of useful extensions to the keyboard interface, such as the command history mechanism, job control, and additional filename wildcards, it would probably be fair to say that its most significant departure from the traditional Bourne shell is its syntax for programming constructs: array variables, variable reference forms in general, arithmetic expressions, and the if, while, foreach, and switch statements.

      Array variables were previously discussed in the section titled "Using Array Variables." The syntax of variable references was discussed in "Obtaining Variable Values with Reference Expressions." The section titled "Using Expressions and Operators in Shell Statements," discusses the use of arithmetic expressions and the special @ command used for calculations. This section looks at the shell statements for flow control: the conditional statements if and switch and the loop control statements while and foreach.

      What Is a Shell Script?

      A shell script is simply a text file containing shell commands. What makes shell scripts especially handy is the ability to execute the commands in the file simply by typing the file's name as if it were a command. To put it another way, shell scripts provide a fairly painless way to add new commands to your UNIX system. A shell script can be as simple or as complicated to write as you choose. It can be designed to be used by yourself alone, or by many people as a general-purpose command.

      Generally you'll want to write a shell script when you recognize either of two situations:

      • You find yourself repeating a lengthy series of commands over and over to accomplish one general task. Any time you need to accomplish a task on a fairly frequent basis (daily, weekly, or maybe several times a day), and the task requires more than one UNIX command, the task is a good candidate for packaging in a shell script.

      • A procedure needs to be established for a formal activity. For example, printing a weekly customer invoicing report might require a complex procedure, extracting billing information from a master file, computing the invoice data, setting up the printer, and actually generating the print file.

      As a general rule, shell scripts written for the purpose tend to be straightforward to write, whereas the more formal procedures demand generalized shell scripts of greater complexity.

      Writing Shell Scripts—An Overview

      Writing a shell script is much like entering commands at the keyboard, with a few important differences:

      • You might want to support arguments on your command. The shell automatically sets any words entered on the command line following your script's name into a set of parameters: shell variables named $1 and $2. You don't need to take any special action to get arguments from the command line—they're already available in the parameter variables when your script begins its execution.

      • You might want to support one or more options with your new command. The shell passes options to your script the same as other arguments: each command-line word is set into the $1 variables (also accessible in the special shell array variable argv[n]). Options, however, can have a complicated structure, especially if you intend to support the standard UNIX convention for options. See the description of the getopt UNIX command for help with processing command-line option strings.

      • Keyboard commands are usually entered with all information customized to the command's use, whereas commands inside shell scripts are often parameterized and can be conditionally executed. You parameterize a command by providing variable references and filename substitutions as the command's arguments instead of literal text. To write alternative sets of commands to handle different situations, you need to use the shell's if, switch, while, and foreach commands. These commands are rarely used at the keyboard but occur heavily in shell scripts.

      You use the same general procedure for writing shell scripts regardless of their purpose:

      1. Develop a text file containing the required commands.

      2. Mark the text file executable, using the chmod command: chmod +x filename.

      3. Test the shell script.

      4. Install the script in its permanent location.

      5. Use it.

      You probably already know how to prepare text files using a text editor. If not, see Chapter 7, "Editing Text Files." You can use any text editor you like, because the shell is interested in only the file's contents, not in how you created it. The text file cannot, however, contain the formatting characters generated by some word processors; it must contain lines identical in format and content to those you would enter at the keyboard. For this reason, you'll probably use a general text editor such as vi to prepare shell script files.

      A text file must be marked executable to be invoked as a command by entering its filename. You can execute a file as a command even if it is not marked executable by naming it as the first argument of a csh command: csh payroll would cause the shell to search for a file named payroll using the standard search path (defined by the path variable), to open the file for reading, and to proceed to execute the commands in the file. But if you mark the payroll file executable, you don't have to type csh first: payroll becomes a new command.

      The shell uses the same search path for locating script files as it does for locating the standard UNIX commands. To invoke a shell script by name, you must store it in a directory listed in your search path. Alternatively, you can add the directory in which the shell script resides to your search path, but naming too many directories in the search path can slow the shell down, so shell scripts are commonly gathered together into a few common directories.

      You'll find that if you do any shell script writing at all, having a directory named bin under your home directory will be very handy. Place all the shell scripts you write for your own personal use in ~/bin, and include the directory ~/bin in your search path. Then, to add a new command to your personal environment, simply write a command script file, mark it executable, and store it in the ~/bin directory: it's ready for use.

      Shell scripts intended for use by a community of users are usually installed in a general directory not owned by any specific user, such as /usr/bin or /usr/local/bin. Most system administrators prefer to store locally written script files in a separate directory from the standard UNIX commands; this makes system maintenance easier. If your installation practices this procedure, you probably already have the path of the local commands directory in your search path. You'll need the help of the system administrator to store a shell script file in such a directory though, because you won't have write access to the directory (unless you're the administrator).

      There is generally nothing magical about testing shell scripts. As a rule, you'll develop a new shell script in a directory you set aside for the purpose. The directory might contain data files you use to test the shell script, and possibly several different versions of the script. You won't want to make the script file accessible to others until you finish testing it.

      Sometimes, if you find the behavior of a shell script confusing and unexplainable, you might find it a help to see the commands the shell is actually executing when you run it. Simply invoke the script with the -x option (for example, csh -x payroll), or embed the command set echo in the script file while you are testing it. With the echo variable set, the shell prints each command just before executing it. You'll see variable substitutions, filename expansions, and other substitutions all expanded, so that you'll know exactly what the shell is doing while running your script. With this trace to look at, you'll probably have no difficulty finding errors in your script file.

      If the output is especially voluminous, you can cut down the range of commands displayed by the shell by bracketing the commands you want to trace: put the command set echo in front of the range of commands to be traced, and the command unset echo at their end. The shell will print just the commands between the set and unset while running your script file. Don't forget to remove the set and unset commands after you finish testing and before putting the shell script into production usage.

      A Simple Shell Script

      Shell scripts can be very easy to write. For example, the following lines, if entered into a file named lld, implement a new command that lists only the directories contained in a directory:

      # lld - long listing of directories only if ($#argv < 1) set argv=(.) find $argv[*] -type d -exec /bin/ls -ld \{\} \;

      The script contains only three commands. The first, a line containing only a shell comment, serves as a heading and description of the file for anyone displaying it. Many shell script writers place one or more comment lines at the beginning of their script files to provide some documentation for others, in case anyone else ever needs to read, change, or enhance the script. Actually, a well-written script file contains many comment lines to help explain the script's operation. Scripts you write for your own use don't need to contain as many comments as scripts written for more public consumption.

      The operative statements in the script do two things:

      • Provide a default command-line argument if the user didn't provide any. In this case, if the user specifies no directory names, the lld command lists the current directory

      • Execute the find UNIX command to locate just the directory files contained in the named directory. The -exec option invokes the ls command for each subdirectory located.

      Even though the lld shell script is short, it serves the useful purpose of hiding the relatively complicated find command from its users. Even for users very familiar with the find command, it is much quicker to type lld than to type the complete find command.

      Using Expressions and Operators in Shell Statements

      There are a number of contexts where the shell requires you to write an expression. An expression is a combination of terms and operators which, when evaluated, yield an arithmetic or logical result. An arithmetic result is always represented as a string of decimal digits. A logical value is either true or false; in the C shell, a true condition is indicated by 1 and a false condition by 0. An arithmetic value can be used where a logical value is expected: any nonzero value will be construed as true and a zero value as false.

      A digit string beginning with 0 (for example, 0177) is considered an octal number. The shell generates decimal numbers in all cases, but wherever a number is permitted, you can provide either a decimal or an octal value.

      Expressions can be used in the @ (arithmetic evaluation), exit, if, and while commands. For these commands, most operators do not need to be quoted; only the < (less than), > (greater than), and | (bitwise or) operators must be hidden from the shell. It is sufficient to enclose an expression or subexpression in parentheses to hide operators from the shell's normal interpretation. Note that the if and while command syntax requires the expression to be enclosed in parentheses.

      When writing an expression, each term and operator in the expression must be a separate word. You usually accomplish this by inserting white space between terms and operators. For example, observe the shell's response to the following two commands. (The @ built-in command is described later in this chapter; it tells the shell to evaluate the expression appearing as its arguments.)

      $ set x=2 y=3 sum $ @ sum=$x*$y 2*3: no match % @ sum=$x * $y % echo $sum 6

      In the first @ command, after substitution the shell saw the statement @ sum=2*3. Because 2*3 is a single word, the shell tries to interpret it as either a number or an operator: it is neither, so the shell complains because the word starts with a digit but contains non-digit characters.

      Most operators have their normal interpretation familiar from the C programming language. Both unary and binary operators are supported. A complete list of the expression operators supported by the C shell appears later.

      Operators combine terms to yield a result. A term can be any of the following:

      A literal number, for example 125 (decimal) or 0177 (octal).

      An expression enclosed in parentheses: (exp). Using a parenthesized expression hides the <, >, and | operators from the shell's normal interpretation. The parenthesized expression is evaluated as a unit to yield a single numeric result, which is then used as the value of the expression. Parentheses override the normal operator precedence.

      Any variable, command, or history substitution (or combination of these) that when evaluated yields a decimal or octal digit string. The usual shell replacement mechanisms are used when scanning an expression. The only requirement you must observe is that, after all substitutions, the resulting words must form decimal or octal digit strings or expressions.

      Arithmetic and Logical Operators

      The operators shown in Table 13.6 can be used to combine numeric terms. Arithmetic operators yield a word consisting of decimal digits. Logical operators yield the string "1" or "0".

        Table 13.6. Arithmetic and logical shell operators.



      Bitwise one's complement. The bits of a are inverted so that 1 yields 0, and 0 yields 1.



      Logical negation. If the value of a is zero, the value of the expression is 1; if the value of a is nonzero, the value of the expression is zero.



      Multiplication. The value of the expression is the arithmetic product of a times b.



      Division. The value of the expression is the integer quotient of a divided by b.



      Remainder. The value of the expression is the remainder from the integer division of a by b.



      Addition. Yields the sum of a and b.



      Subtraction. Yields the sum of a and -b.


      a << b

      Left shift. Shifts a left the number of bits specified by b. Equivalent to a ´ 2b.


      a >> b

      Right shift. Shifts a right the number of bits specified by b. Equivalent to a – 2b.


      a < b

      Less than. Yields 1 if a is less than b, otherwise 0.


      a > b

      Greater than. Yields 1 if a is greater than b, otherwise 0.


      a <= b

      Less than or equal to. Yields 1 if a is not greater than b, otherwise 0.


      a >= b

      Greater than or equal to. Yields 1 if a is not less than b, otherwise 0.


      a =~ b

      Pattern matching. Yields 1 if string a matches pattern b.


      a !~ b

      Pattern matching. Yields 1 if string a does not match pattern b.


      a == b

      String comparison. Yields 1 if a is identical to b, compared as strings.


      a != b

      String comparison. Yields 1 if string a is not identical to string b.


      a | b

      Bitwise or. Yields the inclusive-or of a and b.


      a ^ b

      Bitwise exclusive-or. Yields the exclusive-or of a and b.


      a & b

      Bitwise and. Yields the and of corresponding bits of a and b.


      a && b

      Logical and. Yields 1 if a is true and b is true; otherwise 0 if either is false.


      a || b

      Logical or. Yields 1 if either a is true or b is true (or both are true); otherwise 0.

      Assignment Operators—Evaluating Expressions and Assigning the Results to Variables

      Use the @ command to evaluate an expression and assign the result to a variable, or to an element of an array variable. The special characters <, >, and | must be quoted or enclosed in parentheses if part of the expression; other expression operators can be used without quoting.

      @ @ name=expr @ name[i]=expr

      The assignment operators +=, -=, *=, /=, %=, <<=, >>=, |=, ^=, and &= are also supported. The format name op= expr is equivalent to writing name = name op expr; for example @ x=x+y can be written @ x += y.

      The C operators ++ and — are supported in both postfix and prefix forms within expr. This usage is allowed for the @ command, but not for expr generally.

      Use the form @ name[i]= to assign the result to the ith element of array variable name.

      The variable name (or array element name[i]) must exist prior to execution of the @ command; the @ command will not create it. A variable or array element is considered to exist even if it has a null value.

      Operator Precedence for Arithmetic and Logical Operators

      The shell uses precedence rules to resolve ambiguous expressions, which are expressions containing two or more operators, as in a+b*c. This expression could be interpreted either as (a+b)*c or as a+(b*c). In fact, the latter interpretation applies. Using the values a=3, b=5, and c=7, the expression a+b*c will evaluate to 38, not 56.

      NOTE: To make life easier for everyone, the shell's rules are identical to those of the C language and a superset of the same precedence rules used by the common handheld calculator.

      In Table 13.6, operators appear in decreasing order of precedence. Operators fall into eight precedence groups:

      • Unary operators !, ~, and -. These operators have highest priority. In succession they associate right to left, thus !~a is equivalent to the parenthesized expression !(~a).

      • Multiplicative operators *, /, and %.

      • Additive operators + and -.

      • Shift operators << and >>. The second argument is used as a count and specifies the number of bits by which the first argument should be shifted left or right. Bits shifted out are discarded, for example 5 >> 1 yields 2.

      • Relational operators <, <=, >, and >=. These operators compare their operands as numbers and yield 1 (true) if the relation is true, or 0 (false) if it is not.

      • Equality operators ==, !=, =~, and !~. Note that, unlike other operators, these treat their arguments as strings. This requires caution, because the strings " 10", "10 ", and " 10 " will all appear unequal even though they are numerically equivalent. To compare strings numerically, use an expression such as $val == ($x + 0).

      • Bitwise operators |, ^, and &. These operators combine the internal binary form of their operands, applying an inclusive-or, exclusive-or, or and function to corresponding bits. These operations are defined as follows:

        Inclusive-or: Generates a 1 if either of the arguments bits is 1, thus (in binary), 0110 | 1010 yields 1110.

        Exclusive-or: Generates a 1 if corresponding bits are different, thus (in binary), 0110 ^ 1010 yields 1100.

        And: Generates a 1 if both source bits are 1, thus 0110 & 1010 yields 0010.

      • Logical operators && and ||. These operators accept numeric values and yield 1 or 0.

      Operators for Command Execution and File Testing

      The shell also supports an additional, unconventional set of operators for command execution and file testing in expressions.

      Within an expression, you can write a command enclosed in {} (braces). The value of a command execution is 1 if the command executes successfully, otherwise 0. In other words, a zero exit code yields a value of 1 (logical true) for the command expression {command}; a nonzero exit code yields a value of 0.

      Operators for file testing allow you to determine whether a file exists and what its characteristics are. These operators have the form -f filename and are treated in expressions as complete subexpressions. For filename, specify the name or path of a file, optionally using pattern characters; the argument is subject to all forms of shell substitution, including filename expansion before testing.

      Table 13.7 summarizes the file testing operations supported within expressions.

        Table 13.7. File testing expressions.
      Condition When True

      -r filename

      True if file exists and is readable

      -w filename

      True if file exists and is writable

      -x filename

      True if file exists and is executable

      -e filename

      True if file exists

      -o filename

      True if file exists and is owned by the current real user ID

      -z filename

      True if file exists and is zero length

      -f filename

      True if file exists and is a regular file

      -d filename

      True if file exists and is a directory

      The following is an example of an expression that mixes file test operators with other operators. In this case, the expression tests whether the file is readable and not a directory:

      if (-r $thisfile && ! -d $thisfile) echo Good file

      Entering Comments in Shell Programs

      Quite often when writing programs, program code that was quite logical six months ago might be fairly obscure today. Good programmers annotate their programs with comments. Comments are entered into shell programs by inserting the pound sign (#) special character. When the shell interpreter sees the pound sign, it considers all text to the end of the line as a comment.

      Conditional Statements

      A conditional statement provides a way to describe a choice between alternative actions to the shell. The choice is actually made by the shell while executing commands, based on decision criteria you specify. You write a conditional statement when you want your shell script to react properly to alternative real-world situations, for example to complain when the user omits required command-line arguments, or to create a directory when it is missing.

      The shell supports two (well, three) commands for conditional execution: if, which evaluates an expression to decide which commands should be executed next; and switch, which chooses commands based on matching a string. The if statement is more appropriate for deciding whether or not to execute a command, or to choose between two commands. The switch statement poses a multiple-choice question; it is designed to handle the situation where there are many different actions that could be taken, depending on the particular value of a string.

      The jump command, although not strictly a conditional statement, because it makes no decision, is nonetheless usually used in conjunction with a conditional statement to move around to arbitrary places in a shell script. The jump command, although valuable in some limited contexts, generally leads to poorly structured shell scripts that are difficult to test and difficult to maintain. Experience with the Bourne and Korn shells, which have no jump command, show that its use is never necessary. You should try to avoid the use of the jump statement whenever possible.

      The following sections look at the if and switch statements in more detail.

      The if Statement

      There are really two different forms of the if statement: a single-line command and a multiline command.

      The single-line command has the general syntax if (expr) command. Use this form when you need to conditionally execute only one command. This form of the if statement provides the basic type of conditional execution: either you execute the command or you don't. The expr can be any valid expression as described in the section titled "Using Expressions and Operators in Shell Statements." If the expression evaluates to a nonzero value at runtime, the expression is considered to be true, and the shell executes command. But if the value of the expression, after evaluation, is zero, then the shell simply skips command, doing nothing. In either case, the shell continues to the next consecutive line of the script file.

      CAUTION: Some implementations of the C shell will perform an I/O redirection on command even if expr evaluates to false. Unless you have confirmed that your version of csh works otherwise, you should use redirections on the single-line if statement with this presumption in mind.

      The multiline command has a more complex syntax:

      if (expr) then commands else if (expr) then commands else commands endif

      In this case, the if statement consists of all the lines beginning with if up to and including the endif line. The multiline form provides a way to tell the shell "either do this or do that." More precisely, the shell executes a multiline if statement as follows: Evaluate the expr expression. If the evaluated expression yields a nonzero result, execute the command group (commands) following then up to the next else or endif. If the evaluated expression yields a zero result, skip the command group following then. For else, skip the commands following it up to the next else or endif when the evaluated expression is true, and execute the commands following else when the evaluated expression is false. For endif, simply resume normal command execution. The endif clause performs no action itself; it merely marks the end of the if statement.

      Notice that, in its basic form if...then...else, the multiline form of the if statement provides for choosing between two mutually exclusive actions based on a test. The expr expression provides the basis for the choice. The special words then and else serve to introduce command groups associated with the true and false outcomes, respectively.

      Because both the single-line and multiline forms of the if statement form complete commands, and you can (indeed you must) embed commands within an if statement, you can nest if statements by writing one inside the other; programmers refer to this kind of construction as a nested if statement. Nested if statements are legal but can be potentially confusing if the nesting is carried too far. Generally one level of nesting (an if inside an if) is considered fair and reasonable; two levels deep (an if inside an if inside an if) is treading on thin ice, and three or more levels of nesting implies that you, as the writer, will forever be called upon to make any necessary changes to the script file (the flypaper theory of programmer management). Of course, you are helpless to a certain extent: the amount of nesting you use depends on the job you are trying to do, and not very much on your sense of esthetics.

      In case you haven't got a clear idea of how if statements work, here's an example of a single-line statement:

      if (-d ~/bin) mv newfile ~/bin

      This simple if statement provides an expression that is true only if a file named bin exists in your home directory (~/bin) and is a directory. If the directory exists, the shell proceeds to execute the mv command in the normal fashion. If the directory ~/bin doesn't exist, then the entire expression (-d ~/bin) is false, and the shell goes on to the next line in the script file without executing the mv command: the mv command is skipped. The entire statement can be interpreted as the directive move the file newfile to the directory ~/bin if (and only if) the directory ~/bin exists; otherwise do nothing.

      Here's a more complex example, using the multiline if statement. In this example, the shell is directed to move the file newfile into the directory ~/bin if it exists, otherwise to write an error message to the user's terminal and abandon execution of the shell script:

      if (-d ~/bin) then mv newfile ~/bin else echo ~/bin: directory not found exit 1 endif

      The longer, multiline if statement is the more appropriate of the two examples for many situations, because it provides the user with some feedback when the script can't perform an expected action. Here, the user is given a helpful hint when the if statement fails to move the file as expected: either create the missing directory or stop asking to move files there.

      Even the dreaded nested if statement can arise from natural situations. For example, the following nests a single-line if statement inside a multiline if statement:

      if (-f newfile) then if (! -d ~/bin) mkdir ~/bin mv newfile ~/bin else echo newfile: file not found exit endif

      This last example uses a slightly different approach than the previous two: it begins by dealing with the basic choice between the case where the file to be moved exists or it doesn't. If newfile doesn't exist, then one can reasonably conclude that the user doesn't know what he's talking about: he should never have invoked the shell script containing these lines, so describe the problem to him and abandon the shell script (all done by the lines following else). However, if the file newfile exists, then the script moves the file as expected, creating the directory ~/bin on the fly if it doesn't already exist.

      As the preceding examples show, the if statement is often used in shell scripts as a safety mechanism, testing whether the expected environment actually exists, and warning the user of problems. At the keyboard, you would simply enter the mv command by itself and analyze any error message it reported. When used inside a shell script, the script must decide how to proceed when the mv statement fails, because the user didn't enter the mv command himself—in fact he might not even realize that invoking the shell script implies executing an mv command. The responsible shell script writer takes into account command failures and provides proper handling for all outcomes, producing scripts that behave in a predictable fashion and appear reliable to their users.

      The switch Statement

      The switch statement is like if but provides for many alternative actions to be taken. The general form of the statement follows:

      switch (string) case pattern: commands default: commands endsw

      Literally, the shell searches among the patterns of the following case statements for a match with string. In actual usage, string is usually the outcome of variable and command substitution, filename generation, and possibly other forms of shell substitution. Each case statement between switch and endsw begins a different command group. The shell skips over command groups following case statements up to the first case statement that matches string. It then resumes normal command execution, ignoring any further case and default statements it might encounter. The default: statement introduces a statement group that should be executed if no preceding case statement matched the string. The required endsw statement provides an ending boundary to the switch statement in case the shell is still skipping over commands when it reaches that point: the shell then reverts to normal command execution.

      In practice, you'll usually place a breaksw statement after each commands group, to prevent the shell from executing the commands in case groups after the one that matched. On rare occasions, you'll have two cases where one case requires some additional preliminary processing before the other case: you can then arrange the two case groups so that the shell can continue from one into the other, omitting a breaksw. Being able to arrange case groups to allow fallthrough (as it is called) is rare, however.

      For a simple example, consider the situation where you want your shell script to prompt the user for a choice; the user should respond by typing y (for yes) to proceed, or else n (for no). The switch statement provides a natural implementation because of its string pattern-matching capability:

      echo -n Do you want to proceed? set reply=$< switch ($reply) case y*: mv newfile ~/bin breaksw default: echo newfile not moved endsw

      The echo statement writes a prompt message to the terminal; the -n option causes the cursor to remain poised after the message so that the user can type a reply on the same line. The set statement uses the shell special variable $< to read a line from the terminal, which is then stored as the value of the reply variable. The switch statement tests the value of reply. Although the syntax of switch calls for a simple string between parentheses, variable substitution is performed before analysis of the switch statement, so by the time the shell executes switch, it sees the user's typed response as a string instead of a variable reference. In other words, if the user typed yes, after substitution the shell switch will see the switch statement as if it had been written switch ("yes").

      There is only one case in the switch, and a default case. If the user typed any line beginning with the letter y, the value of $reply will match the pattern string for the first case; the shell will then execute the lines that follow the case statement. When it reaches breaksw, the shell then skips forward to the next endsw statement.

      If the user's typed reply does not begin with the letter y, it won't match any of the case statement patterns (there is only one). This will cause the shell to reach the default: case while still in skipping mode. The effect of default is to start executing statements if the shell is in skipping mode, so the effect is to provide a case where the user doesn't type a y; the shell script prints a little message to the terminal confirming that nothing was done. Normal execution then continues to and beyond the endsw.

      Here's a slightly more advanced example, where the first command-line argument of the shell script could be an option beginning with - (dash). If the argument is an option, the script saves an indication of the option it found for later reference and discards the option. If it finds an unexpected option, it complains with an error message to the user and abandons execution.

      if ($#argv >= 1) then switch ($argv[1]) case -all: set flagall breaksw case -first: set flagfirst breaksw case -last: set flaglast breaksw default: echo Invalid option: $1 exit 1 endsw shift else echo "Usage: [ -first | -last | -all ] filename ..." exit 1 endif

      The example nests a switch statement inside a multiline if statement: if the user provides no command-line arguments, the script skips all the way down to the else statement, prints a brief description of the command's expected argument format, and exits the script. If the user provided at least one argument, a switch statement analyzes the first argument to see which option it is. If the argument matches any of the three strings -first, -last, or -all, it discards the argument after setting an indicator variable. If the argument doesn't match any of the strings, the default: case results in typing the error message Invalid option and terminating again.

      Beginning a Case in switchcase

      For label, specify a pattern-matching expression to be compared to the control expression of the enclosing switch command.

      case label:

      If, for a given execution of the switch command, the control expression of switch matches the pattern label, statements following case will be executed; otherwise, the case statement and statements up to the next case, default, or endsw statement will be skipped.

      The pattern-matching expression label can consist of ordinary characters as well as the wildcard symbols *, ?, and [...]. The pattern will be matched against the argument of select in the same manner as filenames are matched, except that the search here is for a case statement label that matches the select argument.

      For additional information about switch, see the section titled "Conditional Statements" earlier in this chapter.

      The case statement is intended primarily for use in shell scripts.

      Using the Default Case in switchdefault

      Use default to designate a group of statements in the range of a switch statement that should be executed if no other case label matches the switch argument.

      For consistent results, you should place the default statement group after the last case statement group in the switch.

      For more information about the default statement, see the section titled "Conditional Statements" earlier in this chapter.

      The default command is intended primarily for use in shell scripts.

      Exiting from a switch Statement—breaksw

      Use the breaksw command to exit from the immediately enclosing switch statement. The breaksw command causes transfer of control to the statement following the endsw statement. Note that breaksw can exit only from the immediately enclosing switch; any outer switch statements remain active.

      For more information on breaksw, see the section titled "Conditional Statements" earlier in this chapter.

      The breaksw command is intended primarily for use in shell scripts.

      Iterative Statements

      You use iterative statements to repeatedly execute a group of commands. The iterative statements are while and foreach.

      The while Loop

      Use the while statement to repeatedly execute a group of statements until a specified condition occurs. The while command is very generalized. It executes a group of commands repeatedly as long as a calculated expression yields a true result. Some care is needed when writing a while loop, because an improper design could cause the commands to be repeated forever in an unending loop, or never to be executed at all.

      The general syntax of the while command is as follows:

      while (expr) commands... end

      For expr, write a shell expression (see the section titled "Using Expressions and Operators in Shell Statements"). For commands, write one or more commands to be executed on each iteration of the while loop. Simple and compound commands, pipelines, and parenthesized command lists are all valid.

      The shell evaluates expr before the first iteration of the loop, and before each subsequent iteration. If the value of expr is nonzero (in other words, true), then commands is interpreted and executed. Any substitutions contained in commands are performed each time the command is encountered, allowing a different value to be substituted on each iteration.

      When first encountered, the shell processes a while statement much like an if: it evaluates the expression expr: if it is true (nonzero), the shell proceeds with the next statement. Similarly, if expr is false when the shell first encounters the while statement, it skips forward to the end statement, effectively bypassing all the commands between while and end. When you write a while statement, you need to write the test expression expr carefully, realizing that the shell might entirely skip the while statement for certain cases of the expression.

      Here is a simple example of a while statement:

      while ($#argv > 0) if (! -f $1) echo $1: missing shift end

      The while statement evaluates the expression $#argv > 0 on each repetition; that is, it tests to see if there are any command-line arguments. As long as the answer is yes, it executes the following if and shift commands. It stops when the number of command-line arguments has gone to zero, which after enough repetitions of shift it will eventually do. For each repetition, the if command simply tests whether a file exists with the same name as the command-line argument: if not, it writes a warning message. The effect of the while statement is that, invoked with a list of filenames, it lists those where the corresponding file is missing. A similar effect could be obtained by simply entering the command ls name name name..., with the difference that you'd have to pick out the filenames generating a not found message from among the normal ls output, whereas the while example simply lists the files that don't exist.

      while (expr) commands ... end

      The end statement must be used to mark the end of the range of the while loop. It is a valid statement only within the range of the foreach and while statements; elsewhere, it generates a shell error message and the shell halts.

      The foreach Loop

      The foreach command is intended for processing lists. It executes a command group once for each word given as an argument to the foreach command. The shell sets a variable to indicate which argument word the iteration is for; you can use the variable in the repeated commands to take the same general action for each word in the list; hence the name of the command.

      The general syntax of the foreach statement follows:

      foreach name (wordlist) commands end

      For name, specify the name of a shell variable to which the words of wordlist will be assigned in succession. The named variable does not need to be a new one; it can also be an existing variable. However, any current value of the variable will be lost. On exit from the loop, name contains the value of the last word in wordlist.

      For wordlist, specify one or more words enclosed in parentheses. The words can be quoted strings, strings of ordinary characters, variable references, command substitution strings quoted with backquote ('), filename patterns, or history substitutions introduced with !. All of the words are scanned and substitutions performed, and the resulting strings redivided into words (except where prevented by quoting) before the first loop iteration. You can omit the parenthesized wordlist, in which case the shell uses the command-line arguments as the list of words.

      For command, specify one or more complete commands using the normal shell syntax. A command can be a simple or compound command and can be any of the legal command types, including aliases and shell built-in commands.

      The last command must be followed with end as a separate command. It can appear on the same line as the last command, separated from it with the semicolon statement delimiter (;), or on a line by itself. Note that the end command is a valid shell command only when used as in a foreach or while statement; in other contexts it is considered an illegal command and causes a shell error.

      The loop is executed once for each word in wordlist. The variable name is set to the current word before each iteration of the loop, in effect stepping through the wordlist word by word from left to right. It stops when the loop has been executed once for each word. In commands, you can use the value of $name to identify which word the repetition is for, or you can ignore its value. You can even change its value. The shell doesn't care. It simply sets name to each word in turn, stopping when it runs out of words.

      The foreach statement is a very handy tool because it allows you to repeat an action for each item in a list. It is as useful at the keyboard as inside shell scripts. In the following example, it is used to change the suffix of a series of files, renaming them:

      foreach file (main util parse io) mv $file.c $file.C end

      There are two additional, special shell commands you can use in the command list within the scope of foreach or while: these are the continue and break commands.

      The continue command, which takes no arguments, can be used as part of a conditional statement to terminate execution of the current loop iteration, skip the remaining statements in the command list, and immediately begin the next loop iteration. The continue command is provided as a convenience, so that you don't have to use complex if statements to thread a path through the foreach loop; when you've executed all the commands that you want to for the current loop iteration, simply invoke continue to skip the remaining commands and start the next iteration with the first command following foreach.

      The break command terminates the current and all subsequent iterations of the foreach loop; after break, the next statement to be executed will be the one following the end statement. Like continue, break skips all intervening commands between itself and the end statement; unlike continue, break also halts iteration of the loop.

      You can nest foreach and while loop control statements within each other, constructing nested loops. If you do so, you will usually want to use a different control variable name on each inner foreach statement, although the shell doesn't enforce such a restriction. Keep in mind, however, that after execution of an inner foreach loop, the control variable will be changed. Changing the value of the control variable in one of the command statements does not affect the behavior of the foreach statement; on the next iteration, it will be assigned the next word in wordlist in the usual manner.

      When using break and continue, you must remember that they affect only the foreach statement on the same level; you cannot use break or continue to abandon an iteration of any outer loop. To break out of a foreach loop nested two or more levels deep, you would need to use conditional statements (such as if) to test some condition and execute another break or continue statement.

      The following example shows the use of foreach to rename each of a set of files whose names end in .c to a filename ending in .x:

      foreach file (main sub1 sub2) mv $file.c $file.x end

      As shown by the example, it is customary when writing shell scripts to indent commands included in the scope of the foreach statement. The indentation helps to clarify the commands' subordination to the foreach statement and graphically highlights their inclusion in the loop.

      Altering the Order of Command Execution—goto

      Use goto to change the order of command execution.

      goto word

      Ordinarily, commands are executed one after another in succession. The looping statements foreach and while provide the ability to repeat a group of statements a fixed or variable number of times, and the if and switch conditional statements allow choosing between two or more alternative statement groups. Other than this, the general flow of control in statement execution is from the first to the last statement in a shell script or input command sequence. The goto command makes it possible to change the flow of control in an arbitrary way.

      For word, specify an ordinary symbol (a string of characters not enclosed in quotes, not containing blanks or tabs, and not containing any punctuation characters having special meaning to the shell).

      The shell searches the command input stream for a line beginning with word followed immediately by a colon (word:); this forms a statement label. If found, execution resumes with the first command following the label. If the statement label cannot be found, the shell writes an error message and stops.

      The goto command is usually used inside a shell script, in which case the range of statements searched for the label is restricted to the contents of the script file. In any other context, the shell backspaces the input medium as far as possible, then searches forward to the statement label. Backspacing is not supported for the terminal, so the goto statement is limited to the current available command history lines when goto is issued from the keyboard.

      Specifying the Response to a Signal—onintr

      Use onintr to specify the action to be taken when the shell receives a signal.

      onintr onintr - onintr label

      The onintr command is roughly equivalent to the Bourne shell trap command but differs in syntax and usage.

      Specified without arguments, the onintr command sets the default signal action for all signals. Used within a shell script, this will cause most signals to result in termination of the shell script. Used from the keyboard, this resets any special signal handling you might have established with previous onintr commands.

      Use onintr - to disable and ignore all signals. This form is handy when used within a shell script to protect a sensitive series of commands, which if interrupted (abandoned because of shell script termination on receipt of a signal) might leave unwanted files or generate invalid results. Use onintr without arguments to restore the normal default signal actions.

      Use onintr label to cause the shell to perform an implicit goto to the statement label label on receipt of a signal. The shell provides no indication of which signal was received. However, because most signals represent a request for termination, this form of onintr can be used to perform orderly cleanup before exiting from a shell script. You might use onintr label in a shell script, for example, to provide a cleanup routine if the user presses the INTR key, signaling his desire to cancel the shell script's execution. After performing any desired actions, exit the shell script with the exit command.

      For more information about statement labels, see the goto command description in this section.

      Processing an Arbitrary Number of Parameters—shift

      Use shift to shift the shell parameters ($1, $2,_) to the left.

      shift shift name

      After execution, the value of $2 is moved to $1, the value of $3 is moved to $2, and so on. The original value of $1 is discarded, and the total number of shell parameters (as indicated by $argv#) is reduced by one.

      Use shift name to perform the same type of action on the named array variable.

      Interpreting a Script in the Current Shell—source

      Use source to read and interpret a script of shell commands within the current shell environment.

      source name

      No subshell is invoked, and any changes to the environment resulting from commands in the script remain in effect afterward. Possible changes that can result from execution of a script file with source include changing the current directory, creation or alteration of local and environment variables, and definition of command aliases.

      An exit statement encountered in a script interpreted with source will result in exit from the current shell level; if this is your login shell, you will be logged out.

      For name, provide the filename or pathname of a file containing shell commands and statements. The shell will search the current directory path (path variable) for the file if you do not specify a name beginning with /, ./, or ../.

      Customizing Your Shell Environment

      The C shell provides for two initialization scripts, the .cshrc and .login files, and one shutdown procedure, the .logout file.

      The C shell always looks for a file in your home directory named .cshrc whenever it is invoked, whether as a login shell, as a command, implicitly by entering the filename of a shell script as a command, or by a subshell expression enclosed in parentheses.

      The .cshrc script should perform only those initializations that you require for any C shell environment, including shells you invoke from other commands like vi and pg.

      When invoked as a login shell, the .login script is executed to perform any one-time-only initializations you might require. These can include issuing the stty command to define your preferred Erase, Kill, and Intr keys, setting your cdpath, path, and mail variables, and printing the news of the day.

      When you exit from a login shell by typing the EOF key at the start of a line or by entering the exit or logout command, the shell searches for a file named .logout in your home directory. If found, the shell executes it and then terminates. You could, for example, use the .login and .logout scripts to maintain a timesheet log recording your starting and ending times for terminal sessions.

      What to Put in Your .cshrc Initialization File

      You should define command aliases, variable settings, and shell options in your ~/.cshrc file. It is always executed before the .login script, and by placing such definitions in .cshrc, you are assured of having the definitions available in subshells.

      Typical items you will want to have in your .cshrc file include the following:

      alias lx /usr/bin/ls -FC

      You will probably want one or more aliases for the ls command. After developing some experience with UNIX, you'll find that there are certain options you prefer to use when listing directory contents. On some occasions you'll want the long listing given by the -l option, but more often a multicolumn listing of some form will provide the quick overview of directory contents that helps to orient yourself. You can have as many aliases for the ls command as you like, but only one named ls. If you define an alias for ls, remember that it will affect your use of the command in pipelines.

      set ignoreeof

      The ignoreeof option prevents you from logging out by accidentally typing the EOF character (usually Ctrl+d). When this option is set, you must explicitly invoke the exit or logout command to exit from the shell.

      set noclobber

      Some users prefer to use the noclobber option, some don't. If set, you can't accidentally destroy an existing file by redirecting a command's output to it with > filename. If you develop a feeling of frustration after destroying useful files too often with the > operator, by all means try noclobber. Note, however, that it provides no protection from accidentally deleting the wrong files with rm.

      set path=(dirname dirname ...)

      You might want to define your search path in .cshrc instead of .login. Defined in .cshrc, you are assured of always having the same search path available for all invocations of the shell. However, you also prevent inheriting an environment. Most people find that it is sufficient to define the search path in the .login script.

      For further information about variables and how to set them, see the section titled "Variables" earlier in this chapter.

      What to Put in Your .login Initialization File

      The .login script is an excellent place to do the following things: Identify the kind of terminal you are using, perhaps by prompting the user to enter a code. Set the TERM environment variable to match the terminal type; TERM is used by the vi command to send the correct terminal control codes for full-screen operation; it can't work correctly with an incorrect TERM.

      Issue the stty command to set your preferred control keys, for example

      stty erase '^H' kill '^U' intr '^C'

      Set global environment variables:

      setenv TERM vt100 setenv EDITOR /usr/bin/vi setenv PAGER /usr/bin/pg

      Set local variables:

      set path=(/usr/bin /usr/ucb /usr/X/bin $home/bin .) set cdpath=(. .. $home) set mail=(60 /usr/spool/mail/$logname)

      Execute any system commands you find interesting:

      news df

      For further information about variables and how to set them, see the section titled "Variables" earlier in this chapter.

      What to Put in Your .logout File

      There are no standard usages for the .logout file. If you don't have a use for the .logout file, you can omit it without incurring any shell error messages.

      Job Control

      When you type a command on the command-line and press return, the command executes in the foreground, which means that it has your system's undivided attention and ties up your system until it is finished executing. This means that you must wait until that command executes before you can do any other work. For commands or programs that execute quickly, this isn't usually a problem. It is a problem for commands or programs that take minutes or hours to execute, however. By executing commands or programs in the background, you can free up your system immediately to do other tasks.

      C shell provides you with a job control mechanism for executing and managing background jobs.

      NOTE: When csh was implemented years ago, its job control mechanism was quite an advancement. In fact, when the Korn shell was implemented to provide C shell features in a Bourne shell style, the csh job control interface was carried virtually intact and without change. The description of job control in Chapter 12, "Korn Shell," is essentially accurate for the C shell as well.

      The C shell commands provided for managing background processes started with & (called jobs) are as follows:


      Execute a command in the background


      List active background jobs


      Wait for specified (or all) jobs to finish


      Send a signal to specified jobs


      Resume execution of stopped jobs in the background


      Switch background jobs to foreground execution

      Executing Jobs in the Background—&

      Use & to execute a command in the background. A background process has no associated terminal.

      command &

      If the process attempts to read from your terminal, its execution is suspended until you bring the process into the foreground (with the fg command) or cancel it. A command executed in the background is called a job by the C shell.

      For command, write a simple command or a compound command. The & operator must appear at the end of the command. The & operator also serves as a statement delimiter; any commands following & on the same line are treated as if they were written on the following line. The & operator also has lower precedence than any other compound operators. In the following example, all the commands are executed in the background as a single job:

      grep '#include' *.c | pr && echo Ok &

      When you execute a command in the background by appending an &, the shell writes a notification message to your terminal identifying the job number assigned to the job. Use this job number, in the form %number, as the operand of kill, fg, bg, or wait to manipulate the job.

      Listing Active Background Jobs—jobs

      The jobs command simply lists the process group leaders you have active in background execution. The process group leader is the process that owns itself and zero or more additional subprocesses. A simple command appended with & launches one process and one process group leader (that is, one job with one process); a pipe of three commands all executed in the background (for example ls | sed | xargs &) launches three processes but is still one job. See Part IV for more information about processes.

      Use the jobs statement to list the current set of background jobs.

      jobs [ -l ]

      The output of jobs has the following general format:

      % jobs [1] + Stopped vi prog.c [2] Done cc myprog.c

      A plus sign (+) marks the shell's idea of the current job; a minus sign, if shown, marks the previous job. Various messages, including Stopped and Done, can be shown to indicate the job's current status.

      Use option -l to print the process identifier of each job beside its job number.

      fg and bg—Referring to Job Numbers

      Both the bg and fg commands require you to specify a job number. A job number is any of the following:


      A reference to job number n. When you start a job using the & operator, the shell prints a job number you can use to refer to the job later. For example

      % cc myprog.c &
      [1] 27442

      The number in brackets is the job number n. The other number is the process identifier of the job. (For more information about processes, see Part IV, "Process Control.")


      A reference to the most recent background command you executed beginning with string. For string, you can specify only the first command name of the line, but you don't need to specify the entire command name: any unique prefix of the command name will be accepted. Thus, you can use %da to mean the date command, but you couldn't safely use %pr to refer to a print command if you have also used the pr command in the same login session.


      A reference to the most recent background command containing string anywhere in the line. For example, %?myprog would be a valid reference to the job cc myprog.c.


      A reference to the current job: the job you last started, stopped, or referenced with the bg or fg command. In the listing produced by the jobs command, the current job is marked with + and can be referenced with the shorthand notation %+.


      Same as %+.


      A reference to the previous job. In the listing produced by the jobs command, the previous job is marked with - and can be referenced by the shorthand notation %-.

      Moving Foreground Jobs into the Background—bg

      Use the bg command to switch the specified jobs (or the current job, if no job arguments are given) to background execution. If any of the jobs are currently stopped, their execution resumes.

      bg [ job ... ]

      A job running in the background will be stopped automatically if it tries to read from your terminal; the terminal input will not be executed unless the job is switched to foreground execution. If you use the bg command to resume a job that has been stopped for terminal input, the job will immediately stop again when it repeats the pending terminal read request, making the bg command appear to have been ineffective. In such a case, you must either terminate the job (using the kill command) or switch the job to foreground execution and respond to its input request (see the fg command).

      You must use the job number when referring to the job: for example fg %3 or fg %cc. The C shell also supports an abbreviation for the fg command: %10 in itself will switch job 10 to foreground execution, acting as an implied fg command. (The Korn shell doesn't exactly support this, although you can set up an alias to achieve the same effect.)

      Pausing and Resuming Background Jobs

      The Ctrl+z mechanism provides a handy way to stop doing one thing and temporarily do another, then switch back. Although some interactive commands like vi allow you to escape to the shell, not all do. Whether the command does or not, simply press Ctrl+z to temporarily stop the command; you'll immediately get a shell prompt. Now you can do whatever you want. To resume the interrupted command, enter fg %vi (or just %vi). You can get yourself quite confused this way, with three or four jobs stopped. The jobs command provides a quick summary to remind you of what commands you currently have stacked up.

      Moving Background Jobs into the Foreground—fg

      fg switches the specified jobs into foreground execution and restarts any that were stopped.

      fg [ job ... ]

      If you specify no job arguments, the current job is assumed; the current job is the last job you started, stopped, or referenced with the bg or fg command and is identified with a + in the listing produced by the jobs command.

      For job, specify any percent expression as described in the section "fg and bg—Referring to Job Numbers." Note that %5 or %ex (or any of the allowable percent expressions), entered as a command, is equivalent to issuing the fg command with that argument; thus %5 would restart job 5 in the foreground, and %ex would restart the most recent ex command if it is one of your active jobs. (See also the bg, wait, and jobs related commands.)

      Stopping a Background Job—stop

      You can pause a job that is executing in the background with stop.

      stop [ %job ]

      This command sends a STOP signal to the named job, as if the STOP key were pressed (usually Ctrl+z). The job is stopped.

      Use the bg command to resume execution of the stopped job, or fg to bring the job to the foreground and resume its execution.

      To terminate the execution of a background job, use the kill command. See the section titled "Signaling a Process—kill" for details.

      Stopping the Current Shell—suspend

      The suspend command suspends execution of, or stops, the current shell; its effect is the same as pressing the STOP key (ordinarily Ctrl+z).


      Waiting for Background Jobs to Finish—wait

      Use the wait command to wait for all background jobs to finish.


      The shell simply stops prompting for command input until it has received notification of the termination of all background jobs.

      To stop waiting, simply press the return (or Enter) key. The shell will print a summary of all background jobs, then resume prompting for commands in the normal fashion.

      Requesting Notification of Background Job Status Changes—notify

      Use the notify command to request that the shell always report any change in the status of a background job immediately.

      notify [ %job ]

      By default, the shell reports the completion, termination, stoppage, or other status change by writing a message to your terminal just before the command prompt.

      Use notify with no arguments to request immediate notification of background job status changes. Be aware, however, that a notification message might be written to your terminal at inopportune times, such as when it is formatted for full-screen operation; the message could garble a formatted screen.

      Use notify %job to request notification of status change for only the specified job. This form is handy when you run a background command and later decide you need its results before continuing. Rather than repeatedly executing jobs to find out when the background job is done, just issue notify %job to ask the shell to tell you when the job is done.

      For %job, specify any of the job reference formats, as described for the bg command.

      Controlling Background Process Dispatch Priority—nice

      Use the nice command to change the default dispatch priority assigned to batch jobs.

      nice [ +number ] [ command ]

      The idea underlying the nice facility (and its unusual name) is that background jobs should demand less attention from the system than interactive processes. Background jobs execute without a terminal attached and are usually run in the background for two reasons: (1) the job is expected to take a relatively long time to finish, and (2) the job's results are not needed immediately. Interactive processes, however, are usually shells where the speed of execution is critical because it directly affects the system's apparent response time. It would therefore be nice for everyone (others as well as yourself) to let interactive processes have priority over background work.

      UNIX provides a nice command that you can use to launch a background job and at the same time assign it a reduced execution priority. The nice built-in command replaces the UNIX command and adds automation. Whereas the UNIX nice command must be used explicitly to launch a reduced-priority background job, the shell always assigns a reduced execution priority to background jobs; you use the nice command to change the priority the shell assigns.

      Invoked with no arguments, the nice built-in command sets the current nice value (execution priority) to 4. A login shell always assumes a nice value of 0 (same priority as interactive processes); you must execute nice or nice +value to change the nice value (until then you aren't being nice; all your background jobs compete with interactive processes at the same priority).

      Use nice +number to change the default execution priority for background jobs to a positive or zero value: a zero value (nice +0) is the same as interactive priority; positive values correspond to reduced priority, so that nice +5 is a lower priority than nice +4, and nice +6 is a lower priority than nice +5, and so on.

      If you specify command, the nice command launches the command using the default or specified execution priority but doesn't change the default execution priority. For example, nice cc myprog.c launches the compilation using the default priority, whereas nice +7 cc myprog.c launches the compilation with an explicit priority of seven.

      Note that you do not need to append & to the nice command to run a command as a background job; when you specify command, the background operator is assumed.

      Signaling a Process—kill

      Use the kill built-in command to send a signal to one or more jobs or processes.

      kill [ -signal ] job ... kill -l

      The built-in command hides the UNIX kill command; to invoke the UNIX kill command directory, use its full pathname (probably /bin/kill or /usr/bin/kill). The built-in command provides additional features that are not supported by /bin/kill and can be used in the same manner.

      For signal, specify a number or a symbolic signal name. All UNIX implementations support signals 1 through 15; some implementations can support more. By convention, the signals listed in Table 13.8 are always defined.

        Table 13.8. Signals.
      Effect or Meaning



      (Hangup.) Sent to all processes in a process group when the terminal is disconnected by logout or, for a remote terminal, when the terminal connection is dropped.



      (Interrupt.) Sent when the user presses the INTR key (defined by the stty command; usually Ctrl+c; sometimes BREAK).



      (Quit.) Sent when the user presses the QUIT KEY (defined by the stty command; there is no default).



      (Kill.) Sent only by the kill command; it forces immediate termination of the designated process and cannot be ignored or trapped.



      (Bus error.) Usually caused by a programming error, a bus error can be caused only by a hardware fault or a binary program file.



      (Segment violation.) Caused by a program reference to an invalid memory location; can be caused only by a binary program file.



      (Pipe.) Caused by writing to a pipe when no process is available to read the pipe; usually a user error.



      (Termination.) Caused by the kill command or system function. This signal is a gentle request to a process to terminate in an orderly fashion; the process can ignore the signal.

      If you omit signal, the TERM signal is sent by default (unless the -l option is specified, in which case no signal is sent at all).

      For job, specify one or more jobs or process identifiers. A job reference can be any one of the following:


      Specify a job number (as shown by the jobs command).


      Specify a prefix of the job's command name. For example, after cxref myprog.c&, any of the references %cxref, %cxre, %cxr, or %cx can be used (%c is also legal but is probably too ambiguous).


      Specify a string contained anywhere in the job's command. For example, after cxref myprog.c&, the reference %?myprog will identify the job by a portion of its argument.


      Specifies the current job. The current job can be identified using the jobs command: it is marked with +.


      Specifies the previous job. The previous job is marked with - in the output of the jobs command.

      There is no default for job. You must specify at least one job or process to which the signal will be sent.

      The command kill -l can be used to list the valid symbolic signal names. Always use the kill -l command to identify the exact signal names provided when using a new or unfamiliar version of csh.

      Also see the bg, fg, wait, and jobs commands for more information about job control using the C shell.

      Using the Shell's Hash Table

      The C shell's hash table is used to expedite command searches by identifying the directory or directories where a command might be located. The hash table is created based on the directories specified in your path C shell variable. The order in which the directories are specified determines the search order as well as the efficiency of locating commands that you execute.

      For each directory in the search path or hash table, the shell invokes the exec UNIX operating system function to search for the command to be executed. If unsuccessful, the search continues with other possible locations for the command; however, the exec operating system function entails considerable operating system overhead; its use increases system load levels and degrades system performance. Consequently, the effectiveness of the shell's hash table is a matter of concern. C shell provides you with three commands for working with the hash table: hashstat, rehash, and unhash.

      Determining the Effectiveness of the Hash Table—hashstat

      Use the hashstat command to determine the effectiveness of the shell's hash table mechanism.

      $ hashstat

      The statistics printed by hashstat indicate the number of trials needed on average to locate commands, and hence the number of exec function calls per shell command issued. Ideally, every command would be found with one trial. If the hit rate is too low, many directory searches (exec invocations) are occurring for each command executed. You need to reorder the directories in your search path and if possible eliminate directories from your path that don't contain any commands you use. In other words, poor hash table performance is caused by an improperly structured search path, as defined by the path C shell variable. The commands you use most frequently should be located in the directory named first in the path, and successive directories should be referenced less and less frequently. If you list directories in your path that don't contain any commands you use, the shell will waste time searching those directories for commands you do use.

      Rebuilding the Hash Table—rehash

      Use the rehash command to rebuild the shell's hash table. The hash table is used to expedite command execution by reducing the set of directories that need to be searched to locate a particular command.


      The hash table is automatically updated when you change the value of the path variable, but no automatic update is possible when you change the name of an executable file or move executable files in or out of directories in your search path. Changes made by the system administrator to directories containing system commands will also go unnoticed. In such cases, use rehash to resynchronize the shell's hash table with the real world.

      You need to execute the rehash command only when an attempt to execute a command that you know exists in your search path results in a not found message.

      Disabling the Use of the Hash Table—unhash

      Use the unhash command to discontinue the shell's use of a hash table to expedite directory searches for commands. The shell continues to search directories using the path variable for programs in the usual fashion, although with reduced efficiency. See the rehash command to resume usage of the hash table.


      You might want to issue the unhash command while developing a new shell script, or when restructuring the contents of directories listed in your path variable.

      Managing Resource Limits—limit and unlimit

      UNIX imposes a number of limitations on the amount of resources any system user can commit. For each type of resource, there is a system-defined maximum. The system administrator can increase or reduce the size of a limitation, using the limit command, or restore the limitation to its normal value with unlimit. Normal users can also employ the limit and unlimit commands, but only to further restrict resource usage, not to increase it.

      The specific types of resources you can control with the limit and unlimit commands are described below.

      Unless you are the system administrator, changing a resource limit affects only the current process; it doesn't affect any other commands you may be running as background jobs at the same time, and it doesn't affect any other users.

      Manipulating resource limits is not something you do very often: it is of interest mainly to programmers and system administrators involved in problem determination. However, you should be aware of the kinds of limits that exist and what their values are, because a resource limit can cause a command to fail for spurious or misleading reasons. For example, one of the resource limits sets an upper bound on the size of a disk file. If a command you execute tries to write a file bigger than the file size limit, the command may fail, reporting that it is out of disk space. This may lead you to ask the system administrator to give you more disk space. Getting more disk space won't solve the problem, however, because the file size limit won't allow your command to use the space even if it's available. The proper resolution is either to ask the system administrator to change the system's built- in file size limit, or to stop trying to write such large files.

      Displaying or Setting Maximum Resource Limits—limit

      Use the limit command to display or change system maximums that apply to the current invocation of the shell and all commands and jobs you launch from the shell.

      limit [ resource [ maximum ] ]

      UNIX provides a limit command you can use to change the maximum file size you can write with any command. The limit shell built-in command can be used for the same purpose, and to change a number of other limits as well.

      If you specify no arguments, the limit command lists all settable limits currently in effect.

      For resource, specify one of the following. (Note: The resource types you can specify depends on the particular implementation of csh and UNIX you are using.)


      The maximum number of CPU seconds any process can run. A process exceeding this limit will be terminated.


      The maximum number of bytes a file can contain. An attempt to create a new file or to append bytes to a file that would exceed this size will cause the operating system to signal an end-of-medium condition to the program. The UNIX system specifies an upper limit for file size that you cannot change. You can use the limit command to display the limit or to reduce it; you cannot increase it, however, unless you have previously reduced the limit, in which case you can increase it up to the system-defined limit.


      The maximum amount of memory that can be allocated to a program's data and stack area. The system defines a default upper limit for the amount of memory a program can use; you can reduce the limit, or if you previously reduced it you can increase it back up to the system-defined limit.


      The maximum amount of memory the system should allow for a program's stack area. The system defines a maximum size to which any program's stack area can grow. You can reduce the limit, or if you previously reduced it you can increase it back up to the system-defined limit.


      The maximum size of a coredump file that can be written. The system defines a maximum size for core files. You can reduce the limit or increase the limit up to the system-defined limit.

      If you specify resource but omit maximum, the limit command displays the current limit value for the specified resource. Otherwise, specify a number of seconds (for cputime), or a number of kilobytes for any other resource (limit filesize 32 sets the maximum filesize to 32 KB or 32,768 bytes). You can append m to the number to specify megabytes instead of kilobytes: limit datasize 2m sets the maximum program data area to 2,097,152 bytes (2048 KB).

      Canceling a Previous limit Command—unlimit

      Use unlimit to cancel the effect of a previous limit restriction.

      unlimit [ resource ]

      Because the limit command can be used only to reduce system-defined constraints even further (for other than the superuser), the unlimit command restores the named limit (or all limits) to their system-defined maximums.

      See the previous section titled "Displaying or Setting Maximum Resource Limits—limit" for a description of the allowable values for resource.


      When compared to the Bourne shell, facilities provided by the C shell include extensions for both the keyboard environment and the shell programming environment. Besides more filename wildcards, command history, history substitution, and job control, the C shell also provides array variables, arithmetic expressions, a somewhat more convenient if statement, and briefer forms of while and foreach (dropping the useless do of the Bourne shell).

      Virtually all of the features of the C shell are also supported by the Korn shell, in a form more consistent with the syntax and usage of the Bourne shell. Because of its many extensions for both the keyboard user and shell script writer, the C shell is well worth your investigation: you might find that you like it.

      This chapter has provided a quick overview of the C shell syntax and features. A more detailed, though turgid, presentation will also be found in the reference manuals for your particular version of UNIX; you should consult these for the last word on details of its operation. The C shell, being descended from BSD roots, has never been subjected to the same degree of standardization as the System V side of the UNIX family.

      Previous Page Main Page Next Page