A Field Guide to the Metaphors Hiding in Your Man Pages

In her talk on metaphors, designer and programmer Maggie Appleton draws a useful distinction between “figurative metaphors”—the literary flourishes of poetry and prose—and “cognitive metaphors,” the deeply embedded conceptual structures that shape how we think and communicate. The latter, as explored at length in George Lakoff and Mark Johnson’s Metaphors We Live By, aren't just rhetorical devices; they are the invisible scaffolding of everyday language.

The book is filled with examples of how we unconsciously map one domain onto another. Ideas, for instance, are rarely just ideas. We speak of raw facts and half-baked plans (ideas as food), of theories that gave birth to new fields (ideas as people), of thoughts that went out of style (ideas as fashions), or arguments that cut right to the heart of a matter (ideas as cutting instruments). These aren't isolated idioms; they are systematic ways of structuring our understanding.

Software documentation is a rich vein of this same cognitive ore. If human cognition is built on such metaphors, then technical writing—which aims for clarity and precision above all—should surely be a metaphor-free zone. A quick survey of man pages, however, reveals that even the most sterile system calls and configuration files are teeming with them. The result is a fascinating glimpse into how programmers mentally model the abstract entities they work with daily.

Processes Are People, With All Their Drama

One of the most colorful and persistent metaphors in the man pages treats running processes as living beings, complete with families and social relationships. This isn't just anthropomorphism for fun; it provides a framework for understanding complex lifecycle states. Man pages casually refer to the death of a controlling process (man 7 signal) or note when a process group becomes orphaned if its parent exits first (man exit). The terminology gets even more evocative with the concept of “zombie” children who have terminated but await reaping by their parent (man wait).

This personification extends beyond lifecycle events to their general behavior and social standing. Processes don't just block on I/O; some “run” to catch up (man mplayer). A daemon might listen forever for a connection (man nc_openbsd), and if a program died due to a fatal signal, tools like xargs can report on that event (man xargs). Even protocols engage in social rituals; a TLS connection’s initial exchange is called a handshake (man curl). There is a strong sense that a system is a community of actors with their own agency, where a program might look for a debug object (man valgrind) or where a server process can be a local agent (man ssh_config).

This framework can even describe software ethics. For example, the documentation for git-tag assures the user that “Git does not (and it should not) change tags behind users back” (man git-tag), ascribing a sense of propriety to the tool itself.

The Stuff of Data: Eating, Objects, and Containers

If processes are people, data is the world they inhabit—a world we understand through several distinct metaphors.

Data as food is still a common, albeit humorous, mapping. There is a great anecdote in man mkfs about certain digital cameras getting indigestion if they are “fed” a particular CF card. In more technical contexts, a tool like Nmap can send packets using raw ethernet frames (man nmap), and a crucial regex in pcrepattern is described as a greedy construct that can swallow everything it can (man pcrepattern). We continually speak of feeding data to a process, whether it's input to a CGI script or commands to mkfs (man CGI).

Equally common is data as a physical object. Information isn't abstract; it is something with mass and volume that can be manipulated. You can pack more than one certificate into an ASN.1 structure (man gpgsm), a password can travel in the clear over HTTPS (man Net::SSLeay), and output is generated in discrete blocks (man tmux). This objectification is often extended to life and death, as when a command is said to destroy all sessions (man tmux).

Data and resources are also universally modeled as containers and physical spaces. We talk about strings being empty (man valgrind) or having a limit, and of a cache being full (man zathurarc). The concept of limits as containers is powerful: integer values can overflow the buffer they are stored in (man g++), and tables can have overflows (man lnstat). The entire purpose of tools like chroot is to create a metaphorical jail from which an attacker might get out (man chroot).

Machines That Break, Houses With Ceilings

Just as processes can be people, the software they run on can be treated as a machine or physical object. We rely on procedures that can break down under certain conditions (man git-apply). The man ps page even warns that a particular interface is fragile and subject to change, while the documentation for debugfs admits the tool has rough edges (man debugfs)—all physical attributes for non-physical things.

We also tend to structure more abstract environments, like a system's resource limits, using the schema of a building. The kernel doesn't just set a minimum size; it places a floor of 32 pages on a limit (man execve). Conversely, there is a ceiling beyond which a process’s nice value can't be raised (man getrlimit). The compiling of large codebases can even hit a limit, metaphorically smashing into a wall (man gcc). Lower layers of the software stack act as a foundation upon which everything else is built (man Glib).

A similar spatial logic governs orientation and relative position. The stack is riddled with frontends and backends, as seen in man qemu-system and man curl. Code is said to be on top of a system call (man futimens) or passed back to a front end (man sudo_plugin). If a user is behind a router (man mplayer) or a specific task is handled at lower or higher levels of the OS(man getsockopt, man nmap), the entire software hierarchy is conceived as a vertical landscape.

Resources, Wealth, and Trade-offs

The final, pervasive metaphor is that of a **system as a manager of scarce resources**, subject to economic laws from the realm of money and barter.

The most common pattern is to speak of system costs in monetary terms. Certain git operations are described as being very **expensive**, warning the user to proceed with caution (man git-log, man git-filter-branch). Similarly, a process might be rich in functionality, as the fdisk interface is described for scripts (man fdisk). Creating a new thread incurs an extra cost that can be large, and the limit on work done in a softirq handler is called its budget (man sar.sysstat). These aren't just flowery words; they communicate essential facts about computational magnitude and prioritization. This economic lens directly frames performance as consumption: a downloader won't consume your entire bandwidth (man wget), a compiler might consume more memory (man mplayer), or an operation could **eat up** gigabytes of memory (man valgrind).< /p>

Scarcity also implies ownership and loss. A system crash can lead to lost data (man btree), and reusing resources is a key optimization for connections, sessions, and memory (man curl, man gcc, man dig). Wasting resources, too, is a constant concern, with an option even allowing you to avoid wasting bitrate (man bitrate).

---

This brief survey of a few man pages shows that far from being a cold and literal domain, system documentation relies heavily on the same conceptual metaphors we use to structure our understanding of the world. Whether it's treating a process as a living organism with parents and children, data as food to be swallowed, or system resources as a finite budget, these cognitive metaphors do crucial work. They make complex, abstract, and invisible operations tractable by mapping them onto our physical, spatial, and economic experiences.