can be used.
</para>
</listitem>
</varlistentry>
<varlistentry id="docguide-style-ref-pages-exit-status">
<term>Exit Status</term>
<listitem>
<para>
If the program uses 0 for success and non-zero for failure,
then you do not need to document it. If there is a meaning
behind the different non-zero exit codes, list them here.
</para>
</listitem>
</varlistentry>
<varlistentry id="docguide-style-ref-pages-usage">
<term>Usage</term>
<listitem>
<para>
Describe any sublanguage or run-time interface of the program.
If the program is not interactive, this section can usually be
omitted. Otherwise, this section is a catch-all for
describing run-time features. Use subsections if appropriate.
</para>
</listitem>
</varlistentry>
<varlistentry id="docguide-style-ref-pages-environment">
<term>Environment</term>
<listitem>
<para>
List all environment variables that the program might use.
Try to be complete; even seemingly trivial variables like
<envar>SHELL</envar> might be of interest to the user.
</para>
</listitem>
</varlistentry>
<varlistentry id="docguide-style-ref-pages-files">
<term>Files</term>
<listitem>
<para>
List any files that the program might access implicitly. That
is, do not list input and output files that were specified on
the command line, but list configuration files, etc.
</para>
</listitem>
</varlistentry>
<varlistentry id="docguide-style-ref-pages-diagnostics">
<term>Diagnostics</term>
<listitem>
<para>
Explain any unusual output that the program might create.
Refrain from listing every possible error message. This is a
lot of work and has little use in practice. But if, say, the
error messages have a standard format that the user can parse,
this would be the place to explain it.
</para>
</listitem>
</varlistentry>
<varlistentry id="docguide-style-ref-pages-notes">
<term>Notes</term>
<listitem>
<para>
Anything that doesn't fit elsewhere, but in particular