Questions: File Descriptor Tables and I/O Redirection

Question 1

When a shell executes `ls > output.txt`, which sequence of operations does the child process perform before running `ls`?

• A. It modifies the `ls` binary to write to a file instead of the terminal
• B. It closes file descriptor 1, then opens output.txt — which receives fd 1 as the lowest available slot
• C. It opens output.txt as a new file descriptor and passes that number as an argument to `ls`
• D. It tells the kernel to intercept `ls`'s output and redirect it to the file

Answer: (B)

The shell forks a child, which inherits the parent's fd table. Before exec-ing `ls`, the child closes fd 1 (stdout), then calls `open('output.txt', ...)` — the kernel assigns fd 1 because it is now the lowest available integer. When `ls` runs and writes to fd 1 as usual, it writes to the file. The `ls` binary is completely unmodified and unaware that anything changed — it just writes to fd 1 as always.

Question 2

When the shell sets up a pipe for `ls | grep foo`, what does it actually create?

• A. A temporary file that `ls` writes to and `grep` reads from sequentially
• B. A shared memory region that both processes access concurrently
• C. A kernel buffer with a write-end file descriptor wired to `ls`'s stdout and a read-end wired to `grep`'s stdin
• D. A network socket connecting the two processes through the loopback interface

Answer: (C)

A pipe is a kernel-managed buffer with two file descriptors: one for writing (write-end) and one for reading (read-end). The shell creates the pipe, forks both child processes, then wires the pipe's write-end to `ls`'s fd 1 (stdout) and the read-end to `grep`'s fd 0 (stdin) using dup2 or close/open. Each program just reads/writes its standard descriptors as always — neither knows it is connected to the other rather than a terminal.

Question 3

The kernel enforces that file descriptor 1 usually refers to the terminal (stdout), which is why programs can rely on writing to fd 1 to display output.

• T. True
• F. False

Answer: False

File descriptor 1 is just a convention — an integer in the per-process table that can point to any open file, pipe, socket, or device. The kernel assigns no special meaning to fd 1. The convention is established by the shell, which sets up fd 0, 1, and 2 before launching programs. Programs written to write to fd 1 happen to write to whatever that slot currently points to — which could be a terminal, a file, or a pipe, depending on how the shell set things up.

Question 4

When a process is created via fork(), the child process inherits a copy of the parent's file descriptor table.

• T. True
• F. False

Answer: True

fork() creates a copy of the parent's process state, including the file descriptor table. Both parent and child start with the same file descriptors pointing to the same underlying open-file entries in the kernel. This inheritance is what makes shell I/O redirection possible: the shell can set up fds in the child (after fork but before exec) without affecting the parent's own stdin/stdout, and the exec'd program inherits whatever fds the child had arranged.

Question 5

Why can `ls > output.txt` redirect ls's output to a file without any modification to the `ls` source code?

Model answer: Because `ls` writes to file descriptor 1 (stdout) without knowing or caring what that descriptor points to. The shell, not `ls`, performs the redirection: it forks a child process, closes fd 1 in the child, opens output.txt (which gets assigned fd 1), then execs `ls`. From `ls`'s perspective, it just writes to fd 1 as always — the OS transparently delivers those writes to the file. This indirection through integer file descriptors is what makes Unix programs composable without modification.

This is the architectural insight behind Unix I/O: programs operate on abstract integer handles, not on specific files or devices. The kernel mediates all I/O through the fd table, and the shell (or any parent process) can rewire those handles before the program starts. The `dup2()` system call makes this explicit. The same principle underlies piping, network I/O, and terminal multiplexing — all operate on the same abstraction.