A file descriptor (FD) is just a small non-negative integer that your process uses as a handle to any open I/O resource. The kernel keeps a table mapping those integers to the actual underlying objects — whether that's a file on disk, a pipe, a network socket, a terminal, or a special device.
When you call open(), socket(), pipe(), or accept(), the kernel finds the lowest available slot in your process's FD table and returns that number. You pass it to read(), write(), close(), etc.
Every process has its own array of FD slots (default limit 1024, raised with ulimit -n). Slot 0, 1, 2 are pre-filled by the shell with stdin, stdout, stderr. You fill the rest with open() calls.
Each FD slot points to a kernel-side open file description (OFD). The OFD stores the file offset and open flags. Two FDs (even in different processes) can share one OFD — that's what dup() and fork() create.
The OFD points to the inode (for files) or kernel object (for pipes, sockets, etc.). Multiple OFDs can reference the same inode — when all FDs pointing to it are closed, the kernel frees the resource.
Linux extends the UNIX philosophy: sockets, pipes, terminals, /dev/null, /proc entries, timerfd, eventfd — all appear as FDs. Your code calls the same read()/write() regardless of what lies underneath.
Every FD goes through two indirections before reaching the actual resource. Click any row to highlight the chain.
Simulate a process's file descriptor table. Use the buttons on the right to open resources, create pipes, and close FDs. Watch how the kernel fills the lowest available slot.
When you write ./prog > out.txt, the shell does NOT pass a flag to the program. Instead it manipulates the FD table using open() and dup2() between fork() and exec(). The program runs completely unaware; it just writes to fd 1 as always.
Click any redirection to see exactly what FD moves happen.