System administrators (and other human beings too) see a lot of critical messages fly by on the computer screen. It’s often important to save these messages so that you can scrutinize them later, or (all too often) send them to a friend who can figure out what went wrong. So, in this section, we’ll explain a little bit about redirection, a powerful feature provided by Unix shells. If you come from Windows, you have probably seen a similar, but more limited, type of redirection in the command-line interpreter there.

If you put a greater-than sign (>) and a filename after any command, the output of the command will be sent to that file. For instance, to capture the output of ls, you can enter:

$ ls /usr/bin > ~/Binaries

A listing of /usr/bin will be stored in your home directory in a file named Binaries. If Binaries had already existed, the > would wipe out what was there and replace it with the output of the ls command. Overwriting a current file is a common user error. If your shell is csh or tcsh, you can prevent overwriting with the command:

$ set noclobber

In bash, you can achieve the same effect by entering:

$ noclobber=1           It doesn't have to be 1; any value will have the same effect.

Another (and perhaps more useful) way to prevent overwriting is to append new output. For instance, having saved a listing of /usr/bin, suppose we now want to add the contents of /bin to that file. We can append it to the end of the Binaries file by specifying two greater-than signs:

$ ls /bin >> ~/Binaries

You will find the technique of output redirection very useful when you are running a utility many times and saving the output for troubleshooting.

Most Unix programs have two output streams . One is called the standard output, and the other is the standard error. If you’re a C programmer you’ll recognize these: the standard error is the file pointer named stderr to which you print messages.

The > character does not redirect the standard error. It’s useful when you want to save legitimate output without mucking up a file with error messages . But what if the error messages are what you want to save? This is quite common during troubleshooting. The solution is to use a greater-than sign followed by an ampersand. (This construct works in almost every modern Unix shell.) It redirects both the standard output and the standard error. For instance:

$ gcc invinitjig.c >& error-msg

This command saves all the messages from the gcc compiler in a file named error-msg. On the Bourne shell and bash you can also say it slightly differently:

$ gcc invinitjig.c &> error-msg

Now let’s get really fancy. Suppose you want to save the error messages but not the regular output—the standard error but not the standard output. In the Bourne-compatible shells you can do this by entering the following:

$ gcc invinitjig.c 2> error-msg

The shell arbitrarily assigns the number 1 to the standard output and the number 2 to the standard error. So the preceding command saves only the standard error.

Finally, suppose you want to throw away the standard output—keep it from appearing on your screen. The solution is to redirect it to a special file called /dev/null. (Have you heard people say things like “Send your criticisms to /dev/null“? Well, this is where the phrase came from.) The /dev directory is where Unix systems store special files that refer to terminals, tape drives, and other devices. But /dev/null is unique; it’s a place you can send things so that they disappear into a black hole. For example, the following command saves the standard error and throws away the standard output:

$ gcc invinitjig.c 2>error-msg >/dev/null

So now you should be able to isolate exactly the output you want.

In case you’ve wondered whether the less-than sign (<) means anything to the shell: yes, it does. It causes commands to take their input from a file. But most commands allow you to specify input files on their command lines anyway, so this “input redirection” is rarely necessary.

Sometimes you want one utility to operate on the output of another utility. For instance, you can use the sort command to put the output of other commands into a more useful order. A crude way to do this would be to save output from one command in a file and then run sort on it. For instance:

$ du 
 > du_output
$ sort -nr du_output

Unix provides a much more succinct and efficient way to do this using a pipe. Just place a vertical bar between the first and second commands:

$ du | sort -nr

The shell sends all the output from the du program to the sort program.

In the previous example, du stands for “disk usage” and shows how many blocks each file occupies under the current directory. Normally, its output is in a somewhat random order:

$ du
10        ./zoneinfo/Australia
13        ./zoneinfo/US
9         ./zoneinfo/Canada
4         ./zoneinfo/Mexico
5         ./zoneinfo/Brazil
3         ./zoneinfo/Chile
20        ./zoneinfo/SystemV
118       ./zoneinfo
298       ./ghostscript/doc
183       ./ghostscript/examples
3289      ./ghostscript/fonts
        .
        .
        .

So we have decided to run it through sort with the -n and -r options. The -n option means “sort in numerical order” instead of the default ASCII sort, and the -r option means “reverse the usual order” so that the highest number appears first. The result is output that quickly shows you which directories and files hog the most space:

$ du | sort -rn
34368     .
16005     ./emacs
16003     ./emacs/20.4
13326     ./emacs/20.4/lisp
4039      ./ghostscript
3289      ./ghostscript/fonts
        .
        .
        .

Because there are so many files, we had better use a second pipe to send output through the more command (one of the more common uses of pipes):

$ du | sort -rn | more
34368     .
16005     ./emacs
16003     ./emacs/20.4
13326     ./emacs/20.4/lisp
4039      ./ghostscript
3289      ./ghostscript/fonts
        .
        .
        .

An alternative to more could be using the head command here, which only shows the first few lines (10 by default). Of course, if there is a head command, there also needs to be a tail command, which just shows the last few lines.

You may have noticed that when using du alone, the output starts appearing fairly quickly and is then added to as the command finishes more computations, whereas when the output is piped to sort, it will take quite a while (if your hard disk is large and well filled) until the output appears. That is because the sort command needs all the data first in order to be able to sort, and not because the piping would delay things.