Some sections of the MySQL Reference Manual describe programs, such as the sections for mysql and mysqladmin. To avoid writing descriptions for the programs both in the manual and in separate Unix-style man pages (which are written using troff/groff markup), we generate man pages directly from the manual DocBook source. This strategy can be used for other documents as well (for example, the MySQL Test Framework Manual).
Formerly, MySQL distributions contained a set of handwritten man page files, but these were contributed by third parties and rarely were updated, so they became obsolete. Also, there were some programs for which no man pages had ever been written. By generating the man pages from the Reference Manual, we can keep them up to date easily, and we have a man page for every program described in the manual.
If the set of man pages generated from the manual changes, it's
necessary to let the build team know about it. (For example,
they need to update the .spec
files used for
the RPM distributions.) Examples of changes requiring
notification of the build team:
You mark up a new man page in the manual.
You change the “volume” for a man page. For example, mysqld(1) becomes mysqld(8).
You remove a section from which a man page formerly was created. For example, safe_mysqld is no longer present in MySQL 5.1.
The DocBook XSL stylesheets have a man page mode that can be used for generating man page output. The markup described here requires at least version 1.69.0 of the stylesheets, because man page support was improved markedly in that version, and we use features not supported in older versions.
The DocBook XSL stylesheets man page mode requires that man page
sections be marked up using <refentry>
elements. One problem with using
<refentry>
is that the DocBook DTD
prohibits <refentry>
and
<section>
from appearing at the same
level within a document if the document is to be considered valid.
To work around this, we wrap <refentry>
elements within “fake”
<section>
elements so that the source
refman files pass validation. For output generation, we strip off
these fake element tags, and then either pass through the
<refentry>
elements unchanged (for man
page output), or map them onto regular
<section>
elements (for all other output
formats).
The following template shows how to mark up a section so that a
man page can be generated from it. The
<ref...>
tags and their subelements
should be used in the order shown, because the DTD doesn't allow
much flexibility and variations from the order shown typically
result in validation errors.
There must be at least one <refsection>
element per <refentry>
. By convention,
the first should be titled “Description”. If there
are further subdivisions to be made, those should also be marked
up as <refsection>
elements. It is
permissible to nest <refsection>
elements.
Here is a prototype for a manual section that generates a man page:
<section id="fake-id-for-PROGNAME-manpage-section-wrapper"> <title>fake title for PROGNAME man page section wrapper</title> <refentry id="PROGNAME"> <!-- initial index terms go here --> <refmeta> <refentrytitle>PROGNAME</refentrytitle> <manvolnum>VOLNUM</manvolnum> <refmiscinfo class="manual">MySQL Database System</refmiscinfo> <refmiscinfo class="source">MySQL</refmiscinfo> <refmiscinfo class="version">VERSION</refmiscinfo> <refmiscinfo class="refman">PURPOSE-FOR-TITLE</refmiscinfo> </refmeta> <refnamediv> <refname>PROGNAME</refname> <refpurpose>PURPOSE-FOR-MANPAGE</refpurpose> </refnamediv> <refsynopsisdiv> <cmdsynopsis> <command>PROGNAME ARGUMENT-SYNTAX</command> </cmdsynopsis> </refsynopsisdiv> <refsection id="PROGNAME-description"> <title>Description</title> <para> Description of the program, how to use it, its allowable command-line options, and so forth. </para> </refsection> </refentry> </section>
In the template, make the following substitutions:
PROGNAME
= program name
If the program name occurs within an element attribute value,
underscores in the name should be written as dashes. For
example, mysql_config
becomes
mysql-config
.
VOLNUM
= Unix man page
“volume” number
Most of our man pages are part of volume 1. The mysqld and mysqlmanager man pages are in volume 8.
PURPOSE-FOR-TITLE
,
PURPOSE-FOR-MANPAGE
= short phrase
describing program purpose
The purpose string will appear with the program name in the output, but which of the two strings to use depends on the output format. Man pages typically begin with a name section that looks like this, where words in the description are not title-capped:
.SH "NAME" myprog \- a program for doing this and that
Here, “a program for doing this and that” is the
text to use for PURPOSE-FOR-MANPAGE
.
In non-man page output, the name and description become a section title, so words in the description should be title-capped:
<title>myprog - A Program for Doing This and That<title>
Here, “A Program for Doing This and That” is the
text to use for PURPOSE-FOR-TITLE
.
To accommodate both output formats, we include both
description strings in the man page markup. The title-capped
version is included using a
<refmiscinfo>
element (with a
class
attribute of
"refman"
) that does not appear in man page
output. The <refmiscinfo>
element
does not allow much internal markup. In particular,
<literal>
and
<command>
are not allowed.
In some cases, a manual page describes more than one program.
For example, the same material in the MySQL 4.1
Reference Manual describes both
myisamchk and isamchk.
To handle this, include one
<refnamediv>
element for each
program. The first such element should be for the primary
program described by the man page. For example:
<refnamediv> <refname>myisamchk</refname> <refpurpose>MyISAM table-maintenance utility</refpurpose> </refnamediv> <refnamediv> <refname>isamchk</refname> <refpurpose>ISAM table-maintenance utility</refpurpose> </refnamediv>
When the file is processed, the man page stylesheets will
produce a file named myisamchk.1
that
contains the man page contents, and another
“stub” file named isamchk.1
that contains a .so
directive that simply
includes the other page:
.so man1/myisamchk.1
VERSION
= version of MySQL to which the
manual applies (4.1, 5.0, 5.1, and so forth)
If the document is unversioned, omit the version element.
ARGUMENT-SYNTAX
= syntax for any arguments
that the program takes
The <cmdsynopsis>
value describes
program invocation syntax. It appears in the
SYNOPSIS
section of man page output. It
does not appear in non-man page output.
Where the “initial index terms” comment appears,
you may add <indexterm>
elements for
index terms that apply to the program as a whole. Index terms
for specific features probably are better placed near the text
that describes the feature.
Output generation always begins with a preprocessing step. For
non-man page output from a source document
manual.xml
, we generate
manual-prepped.xml
, and then run that through
the appropriate DocBook XSL stylesheets. For man page output, we
generate manual-manprepped.xml
, and run that
through the man page DocBook XSL stylesheets. The preprocessing in
both cases is done using the
xsl.d/dbk-prep.xsl
transform, where the type
of <refentry>
handling to be done is
handled by setting the value of the
$map.refentry.to.section
parameter. See the
comments in dbk-prep.xsl
for more
information.
For man page generation, we also have a postprocessing step that acts on the set of mapages as a whole. The postprocessing script is tools/fixup-manpages.pl. For each man page file, it adds this information:
A SEE ALSO
section that names every
other man page and provides the URL to
the online Reference Manual.
An AUTHOR
section that names MySQL AB and
indicates that the software comes with no warranty.
For the SEE ALSO
section to be generated
properly, fixup-manpages.pl must be invoked
with the names of all man pages as its
arguments. fixup-manpages.pl --help shows the
help message that describes the invocation syntax.