man page
A man page, short for manual page, is a form of software documentation integral to Unix and Unix-like operating systems, providing concise reference information on commands, system calls, library functions, file formats, and other system components.[1] These pages are accessed via theman command, which serves as the system's manual pager to display formatted content stored typically in /usr/share/man directories in nroff or related markup formats.[1] Originating from the first "Unix Programmer's Manual" published on November 3, 1971, by Dennis Ritchie and Ken Thompson for Version 1 AT&T Unix on the PDP-11, man pages evolved from earlier text formatting tools like roff, developed by Ritchie in 1971 to produce the initial structured documentation.[2][3]
Man pages are organized into eight primary sections to categorize content systematically: section 1 covers executable programs and shell commands; section 2 details system calls; section 3 addresses library calls; section 4 describes special files like devices; section 5 explains file formats and conventions; section 6 includes games; section 7 covers miscellaneous topics; and section 8 focuses on system administration commands and daemons.[1][2] Each page follows a standardized structure, including subsections such as NAME (identifying the subject), SYNOPSIS (usage syntax), DESCRIPTION (overview and behavior), OPTIONS (available flags), EXIT STATUS or RETURN VALUE (outcomes), ENVIRONMENT (relevant variables), FILES (related resources), EXAMPLES (practical uses), and SEE ALSO (cross-references).[2] This format, inspired by earlier systems like Multics and CTSS manuals, ensures quick, offline accessibility for users and administrators, making man pages a cornerstone of Unix documentation since their inception.[3]
Over time, man pages have been maintained and enhanced through projects like the Linux man-pages initiative, which documents kernel and C library interfaces for user-space programs, and tools such as groff (introduced in 1989 by James Clark) for modern rendering.[4][3] While originally tied to AT&T Unix developments—building on nroff (1972) and troff (1973) by Joseph F. Ossanna for phototypesetter output—they remain a standard across distributions like Linux and BSD, viewable with commands like man <topic> or man -k <keyword> for searches.[3][1] Their enduring design prioritizes precision and brevity, aiding troubleshooting and learning without requiring internet access.[2]
Usage and Access
Command Usage
Theman command is used to display manual pages for system commands, functions, and other topics on Unix-like operating systems. Its basic syntax is man [options] [[section] page ...], where page specifies the topic (e.g., a command name) and section (optional) restricts the search to a particular manual section, such as 1 for user commands or 2 for system calls.[1] Without specifying a section, man searches in the default order, typically starting with section 1.[1]
Common options enhance functionality for searching and customization. The -k or --apropos option searches manual page descriptions for keywords, equivalent to the apropos command; for example, man -k printf lists pages related to "printf".[1] The -f or --whatis option displays short descriptions for exact page names, similar to whatis; invoking man -f ls shows the one-line summary for the ls command.[1] To specify sections explicitly, use -s list or --sections=list, such as man -s 2 fork to view the system call documentation for fork in section 2.[1] The -M path or --manpath=path option overrides the default search paths, allowing users to point to alternative manual directories, e.g., man -M /custom/man ls.[1]
To retrieve a manual page, users typically enter a command like man [ls](/page/Ls) in the terminal, which formats and displays the page using a pager such as less.[1] For section-specific access, prepend the section number before the page name, as in man 2 [fork](/page/Fork), which directly loads the fork entry from the system calls section without searching others.[1] If multiple matches exist across sections, the -a option displays all of them sequentially.[1]
Environment variables influence man's behavior. MANPATH defines the directories to search for manual pages, overriding compiled defaults if set (e.g., export MANPATH=/usr/local/man:$MANPATH).[1] MANWIDTH controls the output line width for formatting, defaulting to the terminal width or 80 characters; setting it to a fixed value like export MANWIDTH=72 ensures consistent rendering across displays.[1]
If no matching page is found, man outputs an error message such as "No manual entry for X" and exits with status 16, indicating no matches for the specified page, section, or keywords.[1] This helps users verify typos or unavailable documentation promptly.[1]
Online Services
Several online repositories provide web-based access to man pages, enabling users to browse and search documentation without local installation. One prominent example is manpages.debian.org, which hosts a complete repository of man pages extracted from Debian packages across various releases, including stable, testing, and unstable suites. The site features a searchable interface allowing direct navigation via URL patterns, such as specifying suites, packages, sections, and languages, with pages rendered in HTML for easy reading. It is updated periodically to reflect changes in Debian's package ecosystem.[5] Similarly, linux.die.net/man offers an extensive collection of Linux man pages organized by traditional sections (1 through 8, plus L and N for specialized functions), covering user commands, system calls, library functions, and more. Users can search by command name or browse alphabetically within sections, making it suitable for quick reference on diverse Linux utilities. Although some pages may lag behind the latest versions, it remains a widely used resource for general Linux documentation.[6] Ubuntu's manpages.ubuntu.com serves as another key repository, dynamically generating hundreds of thousands of man pages from packages across all supported Ubuntu versions, from long-term support releases to development branches. The manuals are extracted and converted to HTML, with daily updates to ensure currency, and support searching by command, section, or package for targeted access.[7] Services like man.cx provide simplified, searchable interfaces to man pages, drawing from sources such as Debian's testing distribution to compile over 229,000 pages, including translations (as of August 2024). Users enter a command name (optionally with a section number, e.g., ls(1)) in the search box or address bar to retrieve formatted pages instantly, addressing scenarios where local man pages are unavailable. TLDR pages, available at tldr.sh, complement traditional man pages by offering community-maintained, concise summaries focused on practical examples for commands across platforms like Linux, macOS, and Windows. Rather than exhaustive details, TLDR emphasizes common usage scenarios, with web access, downloadable clients, and a GitHub repository for contributions under an MIT license.[8][9] For programmatic retrieval, API-based tools enable developers to integrate man page access into applications. ManKier.com, for instance, provides a RESTful API that allows searching man pages, retrieving descriptions, options, cross-references, and command explanations in structured formats, supporting automated querying without manual browsing. This facilitates embedding documentation in scripts, IDEs, or custom tools.[10] Mobile and cross-platform apps extend remote access to man pages on handheld devices. On Android, the Linux Man Pages app fetches comprehensive GNU/Linux documentation from online sources, allowing users to download sections for offline use while supporting search and section-based navigation. Similar functionality appears in apps like Man Pages Unix/Linux, which pull man pages remotely for on-the-go reference. For iOS, direct native apps are limited, but users can leverage web-based services like those above via mobile browsers or shell emulators such as iSH, which enable remote fetching through integrated Linux environments.[11][12]Internal Structure
Manual Sections
Manual pages are organized into standardized sections, numbered from 1 to 8, to categorize documentation by type and audience, facilitating efficient navigation for users, developers, and administrators.[13] This structure originated in early Unix systems and has been adopted across POSIX-compliant environments, with each section serving a distinct purpose in documenting system components. The section number appears in parentheses after the command or function name, such as[ls](/page/Ls)(1), indicating its category.[13]
The standard sections are as follows:
| Section | Purpose | Examples |
|---|---|---|
| 1 | User commands: Executable programs invoked directly by users in a shell, including utilities for file manipulation, text processing, and system interaction. | ls(1) for listing directory contents; grep(1) for pattern searching.[13] |
| 2 | System calls: Interfaces to kernel operations, typically wrapped by library functions for process control, file I/O, and signaling. | open(2) for opening files; fork(2) for process creation.[13] |
| 3 | Library functions: Standard C library calls excluding system calls, covering string handling, memory management, and mathematical operations. | printf(3) for formatted output; malloc(3) for dynamic memory allocation.[13] |
| 4 | Devices and special files: Descriptions of hardware devices and pseudo-devices accessible via /dev, including drivers and interfaces. | tty(4) for terminal devices; null(4) for a null device sink.[13] |
| 5 | File formats and conventions: Formats of configuration files, data files, and protocols that are human-readable or machine-parsable. | passwd(5) for user account files; fstab(5) for filesystem mounts.[13] |
| 6 | Games and recreational programs: Documentation for entertainment software and simple diversions, often with graphical or interactive elements. | rogue(6) for the dungeon-crawling game; fortune(6) for quote display.[13] |
| 7 | Miscellaneous: Overviews of protocols, standards, character sets, and other topics not fitting elsewhere, such as networking or file system overviews. | ascii(7) for character encoding; uri(7) for uniform resource identifiers.[13] |
| 8 | Administrator commands: Privileged utilities for system maintenance, typically requiring root access, including service management and hardware configuration. | mount(8) for mounting filesystems; useradd(8) for adding users.[13] |
Tcl_Interp(3) resides in section 3 for C APIs, while core Tcl commands like puts(n) are in section n.
Overlaps occur when the same name applies to entries in multiple sections, reflecting different contexts such as user tools versus programming interfaces; users specify the desired section with the man command's section option, e.g., man 1 [printf](/page/Printf) for the shell builtin versus man 3 [printf](/page/Printf) for the library function.[1] Without specification, man displays the lowest-numbered section by default, prioritizing user commands.[1]
Section-specific conventions guide content presentation for clarity; in section 1, command names and options are rendered in boldface to distinguish executables, while section 2 and 3 use italics for function parameters and return values to highlight interfaces.[13] These typographic rules, enforced via formatting macros, ensure consistency across implementations like GNU troff.[13]
Layout
Man pages follow a standardized internal structure to ensure consistent readability across Unix-like systems. The typical layout begins with a NAME section providing a brief synopsis of the command or function, followed by a SYNOPSIS section that outlines the syntax using literal formatting for commands and italicized placeholders for arguments. Subsequent sections include DESCRIPTION, which details the functionality; OPTIONS for command-line flags; RETURN VALUES or EXIT STATUS for output codes; ERRORS for failure conditions; EXAMPLES for usage demonstrations; FILES for relevant paths; SEE ALSO for cross-references; AUTHOR for credits; BUGS for known issues; and HISTORY for version changes.[13] This sequence promotes logical flow, with the placement of sections like OPTIONS or ERRORS varying slightly based on the manual section (e.g., user commands versus library functions).[13] The layout employs troff-based macros from the man macro package to control typography and organization. Document structure is defined using macros such as.SH for bold section headings (e.g., .SH DESCRIPTION) and .PP for starting new paragraphs with no indentation. Indentation for lists or examples is achieved with .RS to begin a relative inset block and .RE to end it, often combined with .IP for marked paragraphs (e.g., .IP \(bu for bullet points). Font changes include .B for bold text, typically for command names or options (e.g., .B -l), and .I for italics, used for arguments or filenames (e.g., .I filename). The SYNOPSIS section often uses .nf and .fi to disable and re-enable text filling, preserving literal formatting for code-like syntax.[14]
Headers and footers are generated automatically via the .TH macro, which specifies the title, section number, date, source, and manual volume (e.g., .TH [LS](/page/Ls) 1 "2025-11-09" "[Linux](/page/Linux)" "User Commands"). This produces centered headers with the command name and section (e.g., "LS(1)"), and footers including the date, page number, and volume description like "User Commands," ensuring quick identification during pagination.[14][13]
For terminal display, man pages are formatted using nroff, which adapts the layout for fixed-width output by wrapping long lines to approximately 65-80 characters and substituting unavailable fonts (e.g., italics as underlines). Modern viewers support enhancements like hyperlinks via ECMA-48 escape sequences (OSC 8), allowing clickable cross-references in SEE ALSO sections, while pagination uses tools like less for scrolling through multi-page content.[14]
Creation and Formatting
Authoring Process
The authoring process for man pages begins with selecting an appropriate markup language, such as the traditional troff-based man macros commonly used in Linux environments or the mdoc markup preferred in BSD systems like FreeBSD. Authors then structure the content according to established layout standards, ensuring inclusion of mandatory sections such as NAME, which provides the command or function name along with a concise one-line description, and SYNOPSIS, which outlines the usage syntax including options and parameters. This workflow emphasizes starting with a plain text source file named after the command followed by its section number (e.g.,ls.1), incorporating semantic macros for formatting, and iteratively testing the draft using tools like groff or mandoc to preview the rendered output.[13][15][16]
Best practices prioritize clarity and user-friendliness to make man pages effective references. Authors should employ active voice to directly describe actions, such as "The command lists files" rather than passive constructions, and include practical examples in the EXAMPLES section to illustrate common usage scenarios, like everyday tasks or edge cases, while avoiding deep dives into internal implementation details that could confuse readers. Content should remain concise, with each sentence on a new line for readability during editing, gender-neutral language to promote inclusivity, and American English spelling conventions where applicable in Linux projects. These guidelines ensure the documentation serves as a quick, reliable aid without overwhelming users.[17][13][18]
In open-source projects, integrating man pages into version control systems like Git is standard practice, allowing collaborative tracking of changes alongside source code. For instance, the GNU project recommends maintaining man pages in repositories only if a dedicated volunteer handles updates, using tools like help2man to generate initial drafts from program output, and storing them under permissive licenses to facilitate contributions. Projects such as the Linux man-pages repository exemplify this by hosting source files in Git, enabling pull requests for improvements.[19]
Maintenance involves regular updates to reflect software evolution, such as revising the SYNOPSIS for new options or adding notes on version-specific behaviors in a HISTORY section. Authors update the document date macro (e.g., .Dd in mdoc or the date in .TH) for substantive changes and test for consistency using lint tools. For distribution integration, man pages are submitted upstream to projects or directly to package maintainers; in Debian, they must accompany programs per policy and can be generated from formats like POD before inclusion in source packages, while FreeBSD encourages community contributions via the source tree with thorough reviews.[17][15][20]
Formatting Tools
Man pages are traditionally formatted using the troff typesetting system, with the GNU implementation known as groff, which serves as the primary front-end for processing roff input files containing man macros.[21] Groff invokes the underlying troff formatter to handle low-level operations such as font changes, spacing, and page layout, ensuring compatibility with classical Unix troff while adding extensions for modern use.[22] To support specialized content, groff employs preprocessors that convert domain-specific markup into roff commands before final formatting. The eqn preprocessor typesets mathematical equations, allowing authors to embed expressions like fractions and integrals using a simple syntax that groff then renders appropriately.[23] Similarly, the tbl preprocessor formats tables from tabular input descriptions, generating structured layouts such as aligned columns and borders within man pages.[24] These tools are invoked automatically via command-line options, such as-e for eqn and -t for tbl, streamlining the conversion of source files into viewable output.[25]
For enhanced portability across Unix-like systems, the mandoc toolset provides a modern alternative to groff, compiling man and mdoc source into formatted output without relying on the full roff ecosystem.[26] Developed primarily for OpenBSD but adopted in FreeBSD, NetBSD, and other systems, mandoc emphasizes speed, small footprint, and strict validation of input syntax, rendering pages in a consistent manner regardless of the host environment.[27] It supports the same macro packages as traditional tools but avoids groff's complexity, making it suitable for resource-constrained setups like embedded systems.[28]
Preprocessing extends beyond core formatters to handle custom needs, such as defining additional macros or adapting content for specific builds, often using utilities like awk and sed in scripts to manipulate roff source dynamically. For internationalization, po4a facilitates translations by extracting translatable strings from man pages into PO files, allowing localization teams to update content while preserving structural macros, then reinjecting the results back into formatted documents.[29] This approach decouples text translation from formatting, supporting multiple languages without altering the original English source.[30]
Formatted man pages support various output devices for distribution and viewing. Groff generates PostScript for high-quality printing via the -Tps option and PDF through integrated drivers like gropdf, enabling archival and printable versions.[31] HTML conversion is achieved directly with groff's -Thtml mode or via dedicated tools like man2html, which parses roff input and produces web-ready markup with hyperlinks and styling.[32] Mandoc similarly outputs to HTML5, PostScript, and PDF, broadening compatibility. In package management systems, such as those in Debian or Arch Linux, formatted man pages are installed into directories like /usr/share/man during software deployment, with tools like groff or mandoc invoked by the man command for on-demand rendering.[33][34]
Alternatives to Man Pages
The GNU Info system serves as a primary alternative to man pages, providing documentation in a hierarchical hypertext format designed for navigation via menus and cross-references. Developed as part of the Texinfo documentation system, Info files are viewed using theinfo command, which allows users to traverse structured nodes rather than linear pages. For instance, executing info gcc displays the GNU Compiler Collection manual in an interactive format, enabling efficient searching and linking between related topics.[35][36]
Modern software tools increasingly rely on Markdown-based documentation for accessibility and simplicity, diverging from the troff-formatted structure of man pages. In Git, the git --help command outputs formatted text that can be configured to plain, HTML, or web formats, often drawing from Markdown sources for clarity in command-line interfaces. Similarly, Rust's Cargo uses cargo doc to generate HTML documentation via rustdoc, which processes Markdown-embedded code comments into browsable API references, emphasizing developer-friendly, web-oriented presentation over terminal-based paging.[37][38]
Integrated help systems further supplement or replace man pages by embedding documentation directly into tools and projects. Command-line utilities commonly include --help or -h flags to display concise usage summaries, adhering to Unix conventions for quick reference without external viewers. README files, typically in Markdown, provide project overviews, installation guides, and usage examples in open-source repositories, serving as the initial entry point for users. Project wikis extend this with collaborative, multi-page Markdown or reStructuredText content, as seen in GitHub wikis for ongoing documentation maintenance. Python's official documentation, generated by Sphinx from reStructuredText sources, produces HTML, PDF, or EPUB outputs, integrating docstrings for automated API coverage in a hyperlinked format.[39][40][41][42]
Emerging formats prioritize machine-readable documentation to enable programmatic access and automation. In container tools like Docker, commands such as docker inspect output structured JSON data detailing resource configurations, allowing scripts and tools to parse metadata without human-readable rendering. This JSON-based approach facilitates integration with APIs and CI/CD pipelines, shifting from static text to dynamic, queryable formats for modern DevOps workflows.[43]
History and Evolution
Origins in Unix
The man page system was invented by Dennis Ritchie and Ken Thompson in 1971 as part of the documentation for the first edition of Unix, developed at AT&T Bell Laboratories. This initial release, targeted for the PDP-11 minicomputer, included the Unix Programmer's Manual, First Edition, published on November 3, 1971, which served as the foundational collection of these online reference pages.[44] Ritchie and Thompson authored the earliest man pages, documenting core system utilities to aid developers in a resource-constrained environment where printed manuals were impractical for frequent reference.[45] Early man pages were formatted using roff, an assembly-language text formatter ported from earlier systems like Multics, enabling simple markup for terminal output on the PDP-11. By the second edition of Unix in 1972, roff had evolved into nroff for enhanced flexibility in producing line-printer-ready documents, while troff emerged shortly thereafter for high-quality typesetting on devices like the Graphic Systems CAT phototypesetter. The first man pages covered essential commands such asls for directory listing and cat for file concatenation, reflecting Unix's emphasis on concise, modular tools. These pages were stored in a dedicated directory structure, accessible via an early version of the man command, which piped the content through nroff for display.
Man pages gained broader standardization through the Berkeley Software Distribution (BSD) in 1979, derived from AT&T's Version 7 Unix and incorporating revised macro packages by Doug McIlroy to improve consistency and readability. This BSD variant, distributed by the University of California, Berkeley, popularized man pages among academic and research users, establishing conventions for section divisions and cross-references that persist today. From BSD, the format spread to AT&T's commercial System V Unix releases starting in 1983, which adopted and extended the structure for enterprise environments, ensuring compatibility across diverging Unix implementations.
A key milestone came with the inclusion of the man command in the POSIX.1 standard (IEEE Std 1003.1-1988), which specified the utility and encouraged a conventional eight-section layout to promote portability among Unix-like systems. Ratified by the IEEE and later adopted as ISO/IEC 9945-1:1990, this specification formalized man pages as an essential interface for system documentation, bridging proprietary variants like BSD and System V.[46][47]
Developments in Modern Systems
In the Linux ecosystem, significant advancements to man pages began in 1995 with the establishment of the man-pages project by Andries Brouwer, which centralized the maintenance and distribution of man pages for the Linux kernel and core utilities as a dedicated repository under the Linux Documentation Project. This project, now hosted on kernel.org, ensures standardized documentation across distributions by providing a comprehensive set of pages that packages can install, addressing the fragmentation seen in early Unix derivatives. Distributions like Fedora have further integrated these through strict packaging policies, requiring man pages for all executables and libraries to be included in RPM packages, with automated checks during builds to enforce completeness and accuracy. Support for man pages has extended beyond Unix-like systems into modern operating environments. On macOS, man pages are built into the operating system and accessed via theman command in the Terminal application, providing documentation for system commands and APIs. In Windows environments, man pages are accessible through subsystems like Windows Subsystem for Linux (WSL), where users can install the manpages package via apt to view Unix-style documentation, and Cygwin, which includes a full man infrastructure for POSIX compatibility in a Windows-native setting.
Internationalization efforts have enhanced man pages' usability in diverse linguistic contexts. The manpages-l10n project, initiated in 2010 under Debian and now collaborative across distributions, coordinates translations of man pages into multiple languages including Czech, Danish, Dutch, Finnish, French, German, Italian, Japanese, Polish, Brazilian Portuguese, Romanian, Russian, Swedish, and Chinese.[48] Concurrently, UTF-8 support was standardized in the groff formatting system around 2012, allowing man pages to render international characters and symbols natively without legacy encoding issues, as implemented in most modern viewers like less and man itself.
Recent trends as of 2025 reflect ongoing adaptations for user experience and inclusivity. Colorized output has become available in enhanced viewers, such as integrating tools like bat or most, which apply syntax highlighting to man pages when invoked via the MANPAGER environment variable, improving readability for complex syntax without altering the core format. Accessibility features have progressed modestly, with efforts like HTML conversions via mandoc enabling screen reader compatibility through semantic markup, though native man viewers remain limited in support for assistive technologies. Emerging but incomplete areas include AI-assisted generation, where tools like GitHub Copilot have been used experimentally to draft man pages for open-source projects, and exploratory concepts for blockchain-verified documentation to ensure tamper-proof updates, though these lack widespread adoption.