Unix is often described with the slogan "everything is a file". What does that actually mean for a program at the system-call level, and where does the abstraction leak?

## What the slogan really claims The accurate version is "everything is a file *descriptor*". When a process opens something, the kernel allocates an entry in that process's descriptor table and returns its index — a small non-negative integer. From then on the process names the object by that integer, and the kernel resolves it to the underlying object. The generic operations are deliberately few: `read`, `write`, `close`, `dup`/`dup2`, `fcntl`, and the readiness calls `select` and `poll`. The second half of the claim is namespace unification: devices are exposed as **special files** in the filesystem (character devices for byte-stream hardware such as terminals, block devices for randomly addressable storage), so `open("/dev/…")` reaches hardware with the same call that reaches a regular file, and later Unix systems extended the idea further by exposing process state through a `/proc` filesystem. ## What it buys **Uniform composition.** A program that reads descriptor 0 works against a file, a terminal, a device or a pipe. Redirection and pipelines exist because of this and nothing else. **One access-control model.** A device node has an owner, a group and permission bits like any other filesystem entry, so granting a user access to a serial port is the same operation as granting access to a document. Without this, every device class would need its own authorisation scheme. **Descriptors as capabilities.** A descriptor is a live handle to an already-authorised object. A privileged process can open something, drop privilege, and keep using the descriptor; on modern Unix systems a descriptor can even be passed to another process over a local socket. Permission is checked at open time, not at every read. **Uniform inheritance.** `fork` duplicates the descriptor table, and descriptors survive `exec` unless marked close-on-exec, which is what lets a shell set up a child's environment before the child's code ever runs. ```c #include <fcntl.h> #include <unistd.h> #include <string.h> int main(void) { const char *msg = "same call, different object\n"; int fd = open("/dev/null", O_WRONLY); /* a device */ write(fd, msg, strlen(msg)); write(STDOUT_FILENO, msg, strlen(msg)); /* whatever descriptor 1 is today */ close(fd); return 0; } ``` ## Where it leaks **Not everything has a path.** A pipe created by `pipe()` has descriptors but no name in the filesystem. An ordinary network socket likewise: only a Unix-domain socket has a filesystem path. So "everything is a file" is not the same as "everything is reachable by opening a path". **The operation set is not uniform.** Sockets are born from `socket()` and then need `bind`, `listen`, `accept`, `connect`, `setsockopt` — none of which apply to a regular file. Terminals need a dedicated control interface for line discipline and terminal attributes. Where no clean call exists, `ioctl` is the catch-all: a single entry point taking an opaque request number and an untyped pointer, which is precisely the shape a uniform interface was supposed to avoid. **Positioning semantics differ.** `lseek` on a pipe, FIFO or socket fails with `ESPIPE`, because those objects have no seekable offset. Code written against regular files and then pointed at a pipe discovers this immediately. **Short reads and short writes.** On a regular file, `read` normally returns the full requested count until end of file. On a pipe, socket or terminal it returns whatever is available right now — a return of 100 for a 4096-byte request is normal, not an error, and a return of 0 means end of file. Every robust Unix program loops. This is the single most common bug caused by taking the abstraction literally. **Blocking behaviour differs.** A regular file is always "ready", so readiness notification is meaningless for it, while pipes and sockets are the whole reason `select` and `poll` exist. ## The honest summary The uniformity is at the level of *naming and lifetime* (a descriptor), and partially at the level of *byte transfer*. It was never total, and Plan 9 — designed by the same group at Bell Labs — was in part an argument that Unix had not taken its own idea far enough. In an interview, the answer that lands is: name the descriptor as the unifying concept, give the concrete win (one permission model, redirection, pipelines), then volunteer a leak such as `ESPIPE` on a pipe or short reads on a socket. That combination shows you have written the code rather than read the slogan.