Classic Shell Scripting - Arnold Robbins [83]
Please clean up unneeded files, as soon as possible.
Thanks,
Your friendly neighborhood system administrator.
EOF
done
Open a file for input and output with <>
Use program <> file to open file for both reading and writing. The default is to open file on standard input.
Normally, < opens a file read-only, and > opens a file write-only. The <> operator opens the given file for both reading and writing. It is up to program to be aware of this and take advantage of it; in practice, there's not a lot of need for this operator.
* * *
Warning
The <> operator was in the original V7 Bourne shell, but it wasn't documented, and historically there were problems getting it to work correctly in many environments. For this reason it is not widely known or used. Although it was standardized in the 1992 POSIX standard, on many systems /bin/sh doesn't support it. Thus, you should probably avoid it if absolute portability is a requirement.
Similar caveats apply to >|. A feature borrowed from the Korn shell, it has been standardized since 1992, although some systems may not support it.
* * *
File Descriptor Manipulation
Internally, Unix represents each process's open files with small integer numbers called file descriptors. These numbers start at zero, and go up to some system-defined limit on the number of open files. Historically, the shell allowed you to directly manipulate up to 10 open files: file descriptors 0 through 9. (The POSIX standard leaves it up to the implementation as to whether it is possible to manipulate file descriptors greater than 9. bash lets you, ksh does not.)
File descriptors 0, 1, and 2 correspond to standard input, standard output, and standard error, respectively. As previously mentioned, each program starts out with these file descriptors attached to the terminal (be it a real terminal or a pseudoterminal, such as an X window). By far the most common activity is to change the location of one of these three file descriptors, although it is possible to manipulate others as well. As a first example, consider sending a program's output to one file and its error messages to another:
make 1> results 2> ERRS
This sends make's[1] standard output (file descriptor 1) to results and its standard error (file descriptor 2) to ERRS. (make never knows the difference: it neither knows nor cares that it isn't sending output or errors to the terminal.) Catching the error messages in a separate file is often useful; this way you can review them with a pager or editor while you fix the problems. Otherwise, a large number of errors would just scroll off the top of your screen. A different take on this is to be cavalier and throw error messages away:
make 1> results 2> /dev/null
The explicit 1 in 1> results isn't necessary: the default file descriptor for output redirections is standard output: i.e., file descriptor 1. This next example sends both output and error messages to the same file:
make > results 2>&1
The redirection > results makes file descriptor 1 (standard output) be the file results. The subsequent redirection, 2>&1, has two parts. 2> redirects file descriptor 2; i.e., standard error. The &1 is the shell's notation for "wherever file descriptor 1 is." In this case, file descriptor 1 is the file results, so that's where file descriptor 2 is also attached. Note that the four characters 2>&1 must be kept together on the command line.
Ordering here is significant: the shell processes redirections left to right. Had the example been:
make 2>&1 > results
the shell would first send standard error to wherever file descriptor 1 is—which is still the terminal—and then change file descriptor 1 (standard output) to be results. Furthermore, the shell processes pipelines before file descriptor redirections, making it possible to send both standard output and standard error down the same pipeline:
make 2>&1 | ...
Finally, the exec command may be used to change the shell's own I/O settings. When used with just I/O redirections and no arguments, exec changes the