.Dd December 1, 2015 (1) .Dt LS 1 .Sh NAME (2) .Nm ls .Nd list directory contents .Sh SYNOPSIS (3) .Nm (4) .Op Fl -libxo (5) .Op Fl ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1, (6) .Op Fl D Ar format (7) .Op Ar (8) .Sh DESCRIPTION (9) For each operand that names a .Ar file of a type other than directory, .Nm displays its name as well as any requested, associated information. For each operand that names a .Ar file of type directory, .Nm displays the names of files contained within that directory, as well as any requested, associated information.
Chapter 11. Manual Pages
Table of Contents
Manual pages, commonly shortened to man pages, were conceived as readily-available reminders for command syntax, device driver details, or configuration file formats. They have become an extremely valuable quick-reference from the command line for users, system administrators, and programmers.
Although intended as reference material rather than tutorials, the EXAMPLES sections of manual pages often provide detailed use case.
Manual pages are generally shown interactively by the man(1) command.
When the user types
man ls, a search is performed for a manual page matching
The first matching result is displayed.
Manual pages are grouped into sections. Each section contains manual pages for a specific category of documentation:
Various markup forms and rendering programs have been used for manual pages. FreeBSD has used groff(7) and the newer mandoc(1). Most existing FreeBSD manual pages, and all new ones, use the mdoc(7) form of markup. This is a simple line-based markup that is reasonably expressive. It is mostly semantic: parts of text are marked up for what they are, rather than for how they should appear when rendered. There is some appearance-based markup which is usually best avoided.
Manual page source is usually interpreted and displayed to the screen interactively. The source files can be ordinary text files or compressed with gzip(1) to save space.
Manual pages can also be rendered to other formats, including PostScript for printing or PDF generation. See man(1).
Manual pages are composed of several standard sections. Each section has a title in upper case, and the sections for a particular type of manual page appear in a specific order. For a category 1 General Command manual page, the sections are:
Name of the command
Format of options and arguments
Description of purpose and usage
Environment settings that affect operation
Error codes returned on exit
Examples of usage
Compatibility with other implementations
Cross-reference to related manual pages
Compatibility with standards like POSIX
History of implementation
People who created the command or wrote the manual page.
Some sections are optional, and the combination of sections for a specific type of manual page vary. Examples of the most common types are shown later in this chapter.
|A Document date and Document title are defined.
|A Section header for the NAME section is defined. Then the Name of the command and a one-line Name description are defined.
|The SYNOPSIS section begins. This section describes the command-line options and arguments accepted.
.Nm) has already been defined, and repeating it here just displays the defined value in the text.
|An Optional Flag called
-libxo is shown.
Fl macro adds a dash to the beginning of flags, so this appears in the manual page as
|A long list of optional single-character flags are shown.
-D flag is defined.
-D flag is given, it must be followed by an Argument.
The argument is a format, a string that tells ls(1) what to display and how to display it.
Details on the format string are given later in the manual page.
|A final optional argument is defined.
Since no name is specified for the argument, the default of
file … is used.
|The Section header for the DESCRIPTION section is defined.
When rendered with the command
man ls, the result displayed on the screen looks like this:
LS(1) FreeBSD General Commands Manual LS(1) NAME ls - list directory contents SYNOPSIS ls [--libxo] [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwxy1,] [-D format] [file ...] DESCRIPTION For each operand that names a file of a type other than directory, ls displays its name as well as any requested, associated information. For each operand that names a file of type directory, ls displays the names of files contained within that directory, as well as any requested, associated information.
Optional values are shown inside square brackets.
The mdoc(7) markup language is not very strict. For clarity and consistency, the FreeBSD Documentation project adds some additional style guidelines:
- Only the first letter of macros is upper case
Always use upper case for the first letter of a macro and lower case for the remaining letters.
- Begin new sentences on new lines
Start a new sentence on a new line, do not begin it on the same line as an existing sentence.
.Ddwhen making non-trivial changes to a manual page
The Document date informs the reader about the last time the manual page was updated. It is important to update whenever non-trivial changes are made to the manual pages. Trivial changes like spelling or punctuation fixes that do not affect usage can be made without updating
- Give examples
Show the reader examples when possible. Even trivial examples are valuable, because what is trivial to the writer is not necessarily trivial to the reader. Three examples are a good goal. A trivial example shows the minimal requirements, a serious example shows actual use, and an in-depth example demonstrates unusual or non-obvious functionality.
- Include the BSD license
Include the BSD license on new manual pages. The preferred license is available from the Committer’s Guide.
Add a space before punctuation on a line with macros. Example:
.Sh SEE ALSO .Xr geom 4 , .Xr boot0cfg 8 , .Xr geom 8 , .Xr gptboot 8
Note how the commas at the end of the
.Xr lines have been placed after a space.
.Xr macro expects two parameters to follow it, the name of an external manual page, and a section number.
The space separates the punctuation from the section number.
Without the space, the external links would incorrectly point to section
Some very common macros will be shown here.
For more usage examples, see mdoc(7), groff_mdoc(7), or search for actual use in /usr/share/man/man* directories.
For example, to search for examples of the
.Bd Begin display macro:
% find /usr/share/man/man* | xargs zgrep '.Bd'
Some macros are used to define logical blocks of a manual page.
Section header. Followed by the name of the section, traditionally all upper case. Think of these as chapter titles.
Followed by the name of the subsection.
Used to divide a
Begin list. Start a list of items.
End a list.
Begin display. Begin a special area of text, like an indented area.
This section shows minimal desired man page contents for several common categories of manual pages.
The preferred basic structure for a section 1 or 8 command:
.Dd August 25, 2017 .Dt EXAMPLECMD 8 .Os .Sh NAME .Nm examplecmd .Nd "command to demonstrate section 1 and 8 man pages" .Sh SYNOPSIS .Nm .Op Fl v .Sh DESCRIPTION The .Nm utility does nothing except demonstrate a trivial but complete manual page for a section 1 or 8 command. .Sh SEE ALSO .Xr exampleconf 5 .Sh AUTHORS .An Firstname Lastname Aq Mt email@example.com
The preferred basic structure for a section 4 device driver:
.Dd August 25, 2017 .Dt EXAMPLEDRIVER 4 .Os .Sh NAME .Nm exampledriver .Nd "driver to demonstrate section 4 man pages" .Sh SYNOPSIS To compile this driver into the kernel, add this line to the kernel configuration file: .Bd -ragged -offset indent .Cd "device exampledriver" .Ed .Pp To load the driver as a module at boot, add this line to .Xr loader.conf 5 : .Bd -literal -offset indent exampledriver_load="YES" .Ed .Sh DESCRIPTION The .Nm driver provides an opportunity to show a skeleton or template file for section 4 manual pages. .Sh HARDWARE The .Nm driver supports these cards from the aptly-named Nonexistent Technologies: .Pp .Bl -bullet -compact .It NT X149.2 (single and dual port) .It NT X149.8 (single port) .El .Sh DIAGNOSTICS .Bl -diag .It "flashing green light" Something bad happened. .It "flashing red light" Something really bad happened. .It "solid black light" Power cord is unplugged. .El .Sh SEE ALSO .Xr example 8 .Sh HISTORY The .Nm device driver first appeared in .Fx 49.2 . .Sh AUTHORS .An Firstname Lastname Aq Mt firstname.lastname@example.org
The preferred basic structure for a section 5 configuration file:
.Dd August 25, 2017 .Dt EXAMPLECONF 5 .Os .Sh NAME .Nm example.conf .Nd "config file to demonstrate section 5 man pages" .Sh DESCRIPTION .Nm is an example configuration file. .Sh SEE ALSO .Xr example 8 .Sh AUTHORS .An Firstname Lastname Aq Mt email@example.com
Testing a new manual page can be challenging.
Fortunately there are some tools that can assist in the task.
Some of them, like man(1), do not look in the current directory.
It is a good idea to prefix the filename with
./ if the new manual page is in the current directory.
An absolute path can also be used.
Use mandoc(1)'s linter to check for parsing errors:
% mandoc -T lint ./mynewmanpage.8
Use textproc/igor to proofread the manual page:
% igor ./mynewmanpage.8
% man ls | vale
textproc/vale is highly configurable. It is advised to read its documentation.
Use man(1) to check the final result of your changes:
% man ./mynewmanpage.8
% man ./mynewmanpage.8 | col -b | vim -R -
Spell-checking with fully-featured dictionaries is encouraged, and can be accomplished by using textproc/hunspell or textproc/aspell combined with textproc/en-hunspell or textproc/en-aspell, respectively. For instance:
% aspell check --lang=en --mode=nroff ./mynewmanpage.8
Last modified on: August 28, 2023 by Fernando Apesteguía