Difference between revisions of "Redirection (Linux)"

Revision as of 16:54, 11 July 2012

Redirection is a function common to most Linux shells which allow standard streams to be redirected to user-specified locations.

Redirecting standard input and standard output

Redirection is usually implemented by placing certain characters (or tokens) between commands. Typically, the syntax of these characters is as follows:

command1 > file1  

executes command1, placing the output in file1.

command1 < file1 

executes command1, using file1 as the source of input (as opposed to the keyboard).

command1 < infile > outfile

combines the two capabilities: command1 reads from infile and writes to outfile

Piping

Programs can be run together such that one program reads the output from another with no need for an explicit intermediate file:

command1 | command2   

executes command1, using its output as the input for command2 (commonly called piping, since the "|" character is known as a "pipe").

A good example for command piping is combining echo with another command to achieve something interactive in a non-interactive shell, e.g.

echo -e "user\npass" | ftp localhost

This would run the ftp client and enter user, press return, then pass.

Redirecting to and from the standard file handles

In shells derived from the original Bourne shell, the first two actions can be further modified by placing a number (the file descriptor) immediately before the character; this will affect which stream is used for the redirection. The Linux standard I/O streams are:

For example:

command1 2> file1

executes command1, directing the standard error stream to file1 (useful since standard error outputs to the terminal by default and is unaffected by redirection unless so specified).

In shells derived from csh (the C shell), the syntax instead appends the & character to the redirect characters, thus achieving a similar result.

Another useful capability is to redirect one standard file handle to another. The most popular variation is to merge standard error into standard output so error messages can be processed together with (or alternately to) the usual output. Example:

find / -name .profile > results 2>&1

will try to find files/directories named CVS in the /root directory. Executed without redirection, it will output hits to stdout and errors (e.g. for lack of privilege to read certain directories) to Stderr. If we redirect standard output to file results, the error messages will continue to spam the console. To see both hits and error messages in file results, we merge stderr (handle 1) into stdout using 2>&1 .

If the merged output is to be piped into another program, the file merge sequence 2>&1 must precede the pipe symbol, thus:

find / -name .profile 2>&1 | less

Swapping STDOUT and STDERR using file descriptors

One can either redirect a file descriptor to a file with > or redirect it to another file descriptor (FD) with >&. In other words:

>name means redirect output to file name.

>&number means redirect output to file descriptor number.

The '&' is needed to tell the shell you mean a file descriptor, not a file name.

A file descriptor is a number that refers to an already open file. The standard ones are 0 for standard input, 1 for standard output (STDOUT), and 2 for standard error (STDERR). One can also use any other number, which will create a new file descriptor, in much the same way when one creates a new variable with var=value.

By default, both file descriptor 1 and 2 go to /dev/tty, so if one were to run somecommand 3>&1 1>&2 2>&3 in a new shell, it will not change anything (except now there is a file descriptor number 3).

But if somewhere earlier in the script it does a redirection using exec (e.g., exec 2>error.log), or the script is run with a command line including redirection (e.g., ./myscript 2>error.log), then swapping STDOUT and STDERR will do something.

So, one could create the following to swap STDOUT and STDERR:

$ exec 3>&1 1>&2 2>&3
$ # ~OR~
$ ./myscript 3>&1 1>&2 2>&3

The 3>&1 in the command line will create a new file descriptor and redirect it to 1 which is STDOUT. Now 1>&2 will redirect the FD 1 to STDERR and 2>&3 will redirect FD 2 to 3 which is STDOUT.

Thus, STDOUT and STDERR have been switched. These are the steps:

1. create a new FD 3 and point it to the FD 1;
2. redirect FD 1 to FD 2. (Note: If the FD in 3 is not saved first, the target is lost.); and
3. redirect FD 2 to FD 3. Now FDs one and two are switched.

If the program now prints something to the FD 1 it will be printed to the FD 2, et vice versa.

One can list the open file descriptors with

$ ls -l /proc/self/fd

Chained pipelines

The redirection and piping tokens can be chained together to create complex commands, for example:

ls | grep '.sh' | sort > shlist    

lists the contents of the current directory, where this output is filtered to only contain lines which contain .sh, sort this resultant output alphabetically, and place the final output in shlist.

This type of construction is used very commonly in Linux shell scripts.

Common standard I/O redirections

Note: These have been tested on a bash shell.

External links

• Using Standard Input and Output
• pv - Pipe Viewer