45.20 Overview: Open Files and File Descriptors

[This introduction is general and simplified. If you're a technical person who needs a complete and exact description, read a book on UNIX programming. -JP]

UNIX shells let you redirect the input and output of programs with operators like > and |. How does that work? How can you use it better? Here's an overview.

When the UNIX kernel starts any process (38.3)- for example, grep, ls, or a shell - it sets up several places for that process to read from and write to. Figure 45.1 shows that.

Figure 45.1: Open Standard I/O Files with No Command-Line Redirection

These places are called open files. The kernel gives each file a number called a file descriptor. But people usually use names for these places instead of the numbers:

• The standard input or stdin (File Descriptor (F.D.) number 0) is the place where the process can read text. This might be text from other programs or from your keyboard.

• The standard output or stdout (F.D. 1) is a place for the process to write its "answers."

• The standard error or stderr (F.D. 2) is where the process can send error messages.

By default, as Figure 45.1 shows, the file that's opened for stdin, stdout, and stderr is /dev/tty-a name for your terminal. This makes life easier for users - and programmers, too. The user doesn't have to tell a program where to read or write because the default is your terminal. A programmer doesn't have to open files to read or write from (in many cases); the programs can just read from stdin, write to stdout, and send errors to stderr.

This gets better. When the shell starts a process (when you type a command at a prompt), you can tell the shell what file to "connect to" any of those file descriptors. For example, Figure 45.2 shows what happens when you run grep and make the shell redirect grep's standard output away from the terminal to a file named grepout.

Figure 45.2: Standard Output Redirected to a File

Programs can read and write files besides the ones on stdin, stdout, and stderr. For instance, in Figure 45.2, grep opened the file somefile itself - it didn't use any of the standard file descriptors for somefile. A UNIX convention is that if you don't name any files on the command line, a program will read from its standard input. Programs that work that way are called filters (1.30).

All shells can do basic redirection with stdin, stdout, and stderr. But, as you'll see in article 45.21, the Bourne shell also handles file descriptors 3 through 9. That's useful sometimes:

• Maybe you have a few data files that you want to keep reading from or writing to. Instead of giving their names, you can use the file descriptor numbers.

• Once you open a file, the kernel remembers what place in the file you last read from or wrote to. Each time you use that file descriptor number while the file is open, you'll be at the same place in the file. That's especially nice when you want to read from or write to the same file with more than one program. For example, the line command on some UNIX systems reads one line from a file - you can call line over and over, whenever you want to read the next line from a file. Once the file has been opened, you can remove its link (name) from the directory (45.10); the process can access the file through its descriptor without using the name.

• When UNIX starts a new subprocess (38.3), the open file descriptors are given to that process. A subprocess can read or write from file descriptors opened by its parent process. A redirected-I/O loop, as in articles 45.22 and 45.23, takes advantage of this.