Everything is
a file.

Linux's defining design choice is "everything is a file." Nearly every resource — a regular file, a directory, a hardware device, a network socket, a pipe between programs, even live kernel state under /proc — is exposed through the same interface: the file. You touch all of them with the same small set of system calls: open, read, write, close. A program reading input doesn't know or care whether the bytes come from a disk file, the keyboard, a socket, or another program — they all arrive as a stream behind a descriptor.

That single abstraction is Linux's great multiplier. Learn one interface and it works everywhere; write one tool and it composes with every other, because they all speak "bytes through a descriptor." It's why the command line is so powerful and why decades-old Unix tools still slot into modern pipelines. Everything below — descriptors, pipes, redirection, fork/exec — is just the machinery that makes this uniform "file" idea real and cheap. Understand the abstraction and the internals stop being a pile of trivia and become variations on one theme.

A file descriptor is a small non-negative integer that names an open resource within a process. Each process owns a file-descriptor table — effectively an array — where the kernel tracks everything it has open. Three descriptors are set up before your code even runs: 0 is standard input, 1 is standard output, 2 is standard error. That's why printf writes to descriptor 1 and errors go to 2.

The rule for new descriptors is beautifully simple and worth remembering: open returns the lowest-numbered free descriptor. Open a file with 0,1,2 taken and you get 3; open another and you get 4; close(3) and the next open reuses 3. This lowest-free rule is exactly what makes redirection work: to send a program's output to a file, the shell closes descriptor 1, then opens the file — which, being the lowest free number, becomes descriptor 1 — so everything the program writes to "stdout" now lands in the file, without the program knowing. A tiny, deterministic allocation rule turns into one of the shell's most-used features.

A pipe is an in-kernel FIFO buffer with two ends: write bytes into one end, read them out the other, in order. It's the mechanism that lets one process's output become another's input — the beating heart of the Unix philosophy of small tools joined together.

The elegance is that a and b are ordinary programs that just read stdin and write stdout — they have no idea they've been chained. The shell did all the wiring with descriptors before either started. That's why you can compose cat log | grep error | wc -l out of three tools that were never designed to know about each other: each speaks only "bytes in, bytes out," and pipes carry the bytes between them. The same primitive underlies networking too — a socket is just another two-ended byte stream behind a descriptor.

Descriptor allocation is deterministic — always the lowest free integer — and closing frees a number for reuse, which is the whole trick behind redirection:

With 0,1,2 taken, open→3, open→4; close(3) then open→3 again. Redirection = close(1) then open(file) so the file lands on descriptor 1.

A pipe is a FIFO: bytes come out in the order they went in, and reading an empty pipe returns nothing (or blocks, in the kernel):

Write [1,2,3,4], read 2 → [1,2], read 2 → [3,4]: first-in-first-out. The runnable version below implements the fd table and a pipe and exercises both rules.

How does a new program start? Linux splits it into two deliberately separate calls, and the split is where the descriptor magic happens. fork() clones the current process — after it, there are two nearly identical processes (parent and child) continuing from the same line, differing only in fork's return value so each knows which it is. exec() then replaces a process's program with a new one: same process identity (same PID, same open file descriptors), entirely new code.

The shell runs a command by combining them: it forks a child, and in the child — before exec — it sets up file descriptors (this is where redirection and pipe wiring happen, since the child still shares the layout), then execs the target program, which inherits those descriptors. That window between fork and exec is precisely why the design is split: it's the moment to arrange "stdout goes to this pipe" before the new program starts and takes over. It's a gorgeous consequence of "everything is a file" — because descriptors survive exec, you can wire a program's inputs and outputs from the outside, and the program just finds its streams already connected. Processes, redirection, and pipelines all fall out of this one two-step dance.

The first practical trap is the file-descriptor leak. Descriptors are a finite per-process resource (there's a hard limit, often ~1024 by default), and every open, socket, or accepted connection you forget to close holds one forever. A long-running server that leaks descriptors eventually hits EMFILE — too many open files and can't accept new connections, a classic production outage. Always close what you open (or use language constructs that close automatically).

Two more that catch people. Pipe buffers are finite and can block: if a reader stops reading, the writer eventually fills the pipe buffer and blocks waiting for space — and if two processes each wait to read what the other must write, you get a deadlock. Pipelines feel like magic until backpressure bites. And zombie/orphan processes: after a child exits, its parent must "reap" it (read its exit status) or it lingers as a zombie in the process table; forget this in a server that spawns children and you leak process slots. The unifying lesson is that Linux's power comes from small, composable mechanisms with sharp edges — descriptors, pipes, processes are cheap and everywhere, which also means you must account for every one you create. Internalize "everything is a file," respect the lifetimes of descriptors and processes, and the system that runs the world stops being a mystery: it's open, read, write, close, forked and piped, all the way down.