Think about all the things a program might interact with:

• A text file saved on your hard drive
• Your keyboard (input device)
• Your monitor or terminal (output device)
• A network connection (socket)
• A pipe between two programs

In older operating systems, each of these needed different functions and different code. Linux unifies them. No matter what you are reading from or writing to, you use the same four system calls: open(), read(), write(), and close().

This uniformity is called the Universal I/O Model. It is one of the defining features of the UNIX/Linux design philosophy.

When you open a file (or any resource) in Linux, the operating system gives you back a small non-negative integer. This is called a file descriptor (often shortened to fd). It is just a number — typically 0, 1, 2, 3, 4, and so on.

Think of it like a token number at a bank. When you arrive at the bank, you get a number. The teller does not know your name or your account details upfront — they just call your number and look up everything from there. Similarly, when you open a file, Linux gives you a number (file descriptor), and all future operations on that file use that number.

Each process (running program) has its own personal set of file descriptors. Process A’s file descriptor 3 and Process B’s file descriptor 3 are completely independent — they can refer to totally different files.

Every single program that runs on Linux automatically gets three file descriptors already open before the program even starts doing anything. You did not ask for them — the operating system gives them to you. These are:

stdin is file descriptor 0. By default, it is connected to your keyboard. When your C program calls scanf() or when a shell script reads with read, it is reading from fd 0.

But here is the interesting part — stdin does not have to be your keyboard. You can redirect it. When you run:

./myprogram < input.txt

The shell makes fd 0 point to input.txt instead of the keyboard. Your program never knew the difference — it still just reads from fd 0. That is the beauty of the abstraction.

stdout is file descriptor 1. By default, it is connected to your terminal screen. When your program does printf(), it is writing to fd 1.

Again, you can redirect it:

./myprogram > output.txt

Now fd 1 points to output.txt. The program still writes to fd 1. It does not know or care where that output actually ends up.

stderr is file descriptor 2. It is also connected to the terminal by default. The reason we have a separate file descriptor for errors (instead of just using stdout) is so that you can redirect normal output to a file while still seeing error messages on your screen.

./myprogram > output.txt 2> errors.txt

Here, normal output goes to output.txt and error messages go to errors.txt — separately. This is extremely useful when debugging long-running programs or scripts.

Your program only sees a small integer. All the complex information — the actual location of the file on disk, the current reading position, the file permissions, the buffer state — is stored inside the kernel. Your fd is just an index into a kernel-managed table.

This design has multiple benefits:

• Security: Programs cannot directly manipulate kernel data structures. They must go through system calls.
• Simplicity: Passing a number around is much easier than passing complex objects.
• Flexibility: The kernel can change how a file is stored internally without breaking your program.

When you open a terminal and run commands, the shell (bash, zsh, etc.) itself keeps fd 0, 1, and 2 open and connected to the terminal. When the shell launches your program, your program is a child process — it automatically inherits copies of those three file descriptors.

This is why your C program can call printf() and see output on the screen without ever explicitly opening a terminal — fd 1 was already set up and inherited from the shell.

Every single file I/O operation in Linux ultimately boils down to these four system calls. We will cover each one in detail in the next posts, but here is the big picture:

Here is the simplest possible walkthrough of what happens when your C program reads a file:

/* Step 1: Open the file — get back a file descriptor */
int fd = open("notes.txt", O_RDONLY);
/* fd is now something like 3 */

/* Step 2: Read from the file into a buffer */
char buffer[100];
int bytes_read = read(fd, buffer, 100);

/* Step 3: Do something with the data */
printf("Read %d bytes: %s\n", bytes_read, buffer);

/* Step 4: Close the file — release the fd */
close(fd);
/* fd 3 is now free for reuse */

This same pattern — open, read/write, close — works for regular files, devices, pipes, and sockets. The only thing that changes is what you pass to open().