File descriptors in c

If you can avoid using anything else your programs will have the advantage of being portable. In this chapter it is assumed that you know the basics of file handling and, in particular, are familiar with the C standard file functions.

There are many occasions when you need to call functions that are provided by the operating system and if the call involves a file then it will generally need to be passed something that corresponds to the native way that the operating system works with files.

A file descriptor is a simple int that is an index into an internal operating system table of open files. Each process has its own table and each such table references a globally held table of files. What all of this means is that most programs running under Linux, or any POSIX operating system, sooner or later have to abandon the C standard way of working with files. This is both good and bad news.

The bad news is, of course, that this is not as portable. The good news is that it is a lower-level way of working with files that makes it possible to do more, in particular they are not buffered. For example, when you use the find command, successful output goes to stdout file descriptor 1 , and error messages go to stderr file descriptor 2. Both streams display as terminal output:.

We're getting errors because find is trying to search a few system directories that we don't have permission to read. All the lines that say "Permission denied" were written to stderr, and the other lines were written to stdout. Understanding the difference between stdout and stderr is important when you want to work with a program's output. For example, if you try to grep the output of the find command, you'll notice the error messages are not filtered, because only the standard output is piped to grep.

However, you can redirect standard error to standard output, and then grep will process the text of both:.

For more information about data stream redirection, see pipelines in the bash shell. Another entry is then created in another, per-process table, called the user file descriptor table. This entry points to the previous one in the kernel file table , and just like any entry in a table, it is given an index number.

This index is what the process perceives as the file descriptor. For this reason, when you call open for the first time in a program, you're very likely to get file descriptor 3. Then will come 4, and 5, and so on This file descriptor may then be used as a handle for every operation system call you want to perform on the file : read , write , lseek and close which releases the file descriptor. You may refer to these system call's man pages for more information.

It is also very common to find system calls used by a library function in this function's man mage. For instance, in man fopen , you'll see :. Now, the notions of stream and inode are a little different. The first one is purely conceptual in C : the data stream is what you make of it using the read and write system calls.

The inode number, on the other hand, is associated to storage management more than it is to file access. On a file system, each file is associated to a data structure, stored in the filesystem's superblock. This data structure called the inode holds several pieces of metainformation about the file, such as :.

This inode also allows the kernel to locate where the pieces of a file may be found on disk. Bach chapter 4, section 1, "Inodes". You might also be interested in this.