1 | @rem = '--*-Perl-*--
|
---|
2 | @echo off
|
---|
3 | if "%OS%" == "Windows_NT" goto WinNT
|
---|
4 | perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
|
---|
5 | goto endofperl
|
---|
6 | :WinNT
|
---|
7 | perl -x -S %0 %*
|
---|
8 | if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl
|
---|
9 | if %errorlevel% == 9009 echo You do not have Perl in your PATH.
|
---|
10 | if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul
|
---|
11 | goto endofperl
|
---|
12 | @rem ';
|
---|
13 | #!perl
|
---|
14 | #line 15
|
---|
15 | eval 'exec c:\shaoqunWu\perl\bin\perl.exe -S $0 ${1+"$@"}'
|
---|
16 | if $running_under_some_shell;
|
---|
17 |
|
---|
18 | # pod2man -- Convert POD data to formatted *roff input.
|
---|
19 | # $Id: pod2man.PL,v 1.10 2002/07/15 05:45:56 eagle Exp $
|
---|
20 | #
|
---|
21 | # Copyright 1999, 2000, 2001 by Russ Allbery <[email protected]>
|
---|
22 | #
|
---|
23 | # This program is free software; you may redistribute it and/or modify it
|
---|
24 | # under the same terms as Perl itself.
|
---|
25 |
|
---|
26 | require 5.004;
|
---|
27 |
|
---|
28 | use Getopt::Long qw(GetOptions);
|
---|
29 | use Pod::Man ();
|
---|
30 | use Pod::Usage qw(pod2usage);
|
---|
31 |
|
---|
32 | use strict;
|
---|
33 |
|
---|
34 | # Silence -w warnings.
|
---|
35 | use vars qw($running_under_some_shell);
|
---|
36 |
|
---|
37 | # Insert -- into @ARGV before any single dash argument to hide it from
|
---|
38 | # Getopt::Long; we want to interpret it as meaning stdin (which Pod::Parser
|
---|
39 | # does correctly).
|
---|
40 | my $stdin;
|
---|
41 | @ARGV = map { $_ eq '-' && !$stdin++ ? ('--', $_) : $_ } @ARGV;
|
---|
42 |
|
---|
43 | # Parse our options, trying to retain backwards compatibility with pod2man but
|
---|
44 | # allowing short forms as well. --lax is currently ignored.
|
---|
45 | my %options;
|
---|
46 | Getopt::Long::config ('bundling_override');
|
---|
47 | GetOptions (\%options, 'section|s=s', 'release|r:s', 'center|c=s',
|
---|
48 | 'date|d=s', 'fixed=s', 'fixedbold=s', 'fixeditalic=s',
|
---|
49 | 'fixedbolditalic=s', 'name|n=s', 'official|o', 'quotes|q=s',
|
---|
50 | 'lax|l', 'help|h', 'verbose|v') or exit 1;
|
---|
51 | pod2usage (0) if $options{help};
|
---|
52 |
|
---|
53 | # Official sets --center, but don't override things explicitly set.
|
---|
54 | if ($options{official} && !defined $options{center}) {
|
---|
55 | $options{center} = 'Perl Programmers Reference Guide';
|
---|
56 | }
|
---|
57 |
|
---|
58 | # Verbose is only our flag, not a Pod::Man flag.
|
---|
59 | my $verbose = $options{verbose};
|
---|
60 | delete $options{verbose};
|
---|
61 |
|
---|
62 | # This isn't a valid Pod::Man option and is only accepted for backwards
|
---|
63 | # compatibility.
|
---|
64 | delete $options{lax};
|
---|
65 |
|
---|
66 | # Initialize and run the formatter, pulling a pair of input and output off at
|
---|
67 | # a time.
|
---|
68 | my $parser = Pod::Man->new (%options);
|
---|
69 | my @files;
|
---|
70 | do {
|
---|
71 | @files = splice (@ARGV, 0, 2);
|
---|
72 | print " $files[1]\n" if $verbose;
|
---|
73 | $parser->parse_from_file (@files);
|
---|
74 | } while (@ARGV);
|
---|
75 |
|
---|
76 | __END__
|
---|
77 |
|
---|
78 | =head1 NAME
|
---|
79 |
|
---|
80 | pod2man - Convert POD data to formatted *roff input
|
---|
81 |
|
---|
82 | =head1 SYNOPSIS
|
---|
83 |
|
---|
84 | pod2man [B<--section>=I<manext>] [B<--release>=I<version>]
|
---|
85 | [B<--center>=I<string>] [B<--date>=I<string>] [B<--fixed>=I<font>]
|
---|
86 | [B<--fixedbold>=I<font>] [B<--fixeditalic>=I<font>]
|
---|
87 | [B<--fixedbolditalic>=I<font>] [B<--name>=I<name>] [B<--official>]
|
---|
88 | [B<--lax>] [B<--quotes>=I<quotes>] [B<--verbose>]
|
---|
89 | [I<input> [I<output>] ...]
|
---|
90 |
|
---|
91 | pod2man B<--help>
|
---|
92 |
|
---|
93 | =head1 DESCRIPTION
|
---|
94 |
|
---|
95 | B<pod2man> is a front-end for Pod::Man, using it to generate *roff input
|
---|
96 | from POD source. The resulting *roff code is suitable for display on a
|
---|
97 | terminal using nroff(1), normally via man(1), or printing using troff(1).
|
---|
98 |
|
---|
99 | I<input> is the file to read for POD source (the POD can be embedded in
|
---|
100 | code). If I<input> isn't given, it defaults to STDIN. I<output>, if given,
|
---|
101 | is the file to which to write the formatted output. If I<output> isn't
|
---|
102 | given, the formatted output is written to STDOUT. Several POD files can be
|
---|
103 | processed in the same B<pod2man> invocation (saving module load and compile
|
---|
104 | times) by providing multiple pairs of I<input> and I<output> files on the
|
---|
105 | command line.
|
---|
106 |
|
---|
107 | B<--section>, B<--release>, B<--center>, B<--date>, and B<--official> can be
|
---|
108 | used to set the headers and footers to use; if not given, Pod::Man will
|
---|
109 | assume various defaults. See below or L<Pod::Man> for details.
|
---|
110 |
|
---|
111 | B<pod2man> assumes that your *roff formatters have a fixed-width font named
|
---|
112 | CW. If yours is called something else (like CR), use B<--fixed> to specify
|
---|
113 | it. This generally only matters for troff output for printing. Similarly,
|
---|
114 | you can set the fonts used for bold, italic, and bold italic fixed-width
|
---|
115 | output.
|
---|
116 |
|
---|
117 | Besides the obvious pod conversions, Pod::Man, and therefore pod2man also
|
---|
118 | takes care of formatting func(), func(n), and simple variable references
|
---|
119 | like $foo or @bar so you don't have to use code escapes for them; complex
|
---|
120 | expressions like C<$fred{'stuff'}> will still need to be escaped, though.
|
---|
121 | It also translates dashes that aren't used as hyphens into en dashes, makes
|
---|
122 | long dashes--like this--into proper em dashes, fixes "paired quotes," and
|
---|
123 | takes care of several other troff-specific tweaks. See L<Pod::Man> for
|
---|
124 | complete information.
|
---|
125 |
|
---|
126 | =head1 OPTIONS
|
---|
127 |
|
---|
128 | =over 4
|
---|
129 |
|
---|
130 | =item B<-c> I<string>, B<--center>=I<string>
|
---|
131 |
|
---|
132 | Sets the centered page header to I<string>. The default is "User
|
---|
133 | Contributed Perl Documentation", but also see B<--official> below.
|
---|
134 |
|
---|
135 | =item B<-d> I<string>, B<--date>=I<string>
|
---|
136 |
|
---|
137 | Set the left-hand footer string to this value. By default, the modification
|
---|
138 | date of the input file will be used, or the current date if input comes from
|
---|
139 | STDIN.
|
---|
140 |
|
---|
141 | =item B<--fixed>=I<font>
|
---|
142 |
|
---|
143 | The fixed-width font to use for vertabim text and code. Defaults to CW.
|
---|
144 | Some systems may want CR instead. Only matters for troff(1) output.
|
---|
145 |
|
---|
146 | =item B<--fixedbold>=I<font>
|
---|
147 |
|
---|
148 | Bold version of the fixed-width font. Defaults to CB. Only matters for
|
---|
149 | troff(1) output.
|
---|
150 |
|
---|
151 | =item B<--fixeditalic>=I<font>
|
---|
152 |
|
---|
153 | Italic version of the fixed-width font (actually, something of a misnomer,
|
---|
154 | since most fixed-width fonts only have an oblique version, not an italic
|
---|
155 | version). Defaults to CI. Only matters for troff(1) output.
|
---|
156 |
|
---|
157 | =item B<--fixedbolditalic>=I<font>
|
---|
158 |
|
---|
159 | Bold italic (probably actually oblique) version of the fixed-width font.
|
---|
160 | Pod::Man doesn't assume you have this, and defaults to CB. Some systems
|
---|
161 | (such as Solaris) have this font available as CX. Only matters for troff(1)
|
---|
162 | output.
|
---|
163 |
|
---|
164 | =item B<-h>, B<--help>
|
---|
165 |
|
---|
166 | Print out usage information.
|
---|
167 |
|
---|
168 | =item B<-l>, B<--lax>
|
---|
169 |
|
---|
170 | No longer used. B<pod2man> used to check its input for validity as a manual
|
---|
171 | page, but this should now be done by L<podchecker(1)> instead. Accepted for
|
---|
172 | backwards compatibility; this option no longer does anything.
|
---|
173 |
|
---|
174 | =item B<-n> I<name>, B<--name>=I<name>
|
---|
175 |
|
---|
176 | Set the name of the manual page to I<name>. Without this option, the manual
|
---|
177 | name is set to the uppercased base name of the file being converted unless
|
---|
178 | the manual section is 3, in which case the path is parsed to see if it is a
|
---|
179 | Perl module path. If it is, a path like C<.../lib/Pod/Man.pm> is converted
|
---|
180 | into a name like C<Pod::Man>. This option, if given, overrides any
|
---|
181 | automatic determination of the name.
|
---|
182 |
|
---|
183 | Note that this option is probably not useful when converting multiple POD
|
---|
184 | files at once. The convention for Unix man pages for commands is for the
|
---|
185 | man page title to be in all-uppercase even if the command isn't.
|
---|
186 |
|
---|
187 | =item B<-o>, B<--official>
|
---|
188 |
|
---|
189 | Set the default header to indicate that this page is part of the standard
|
---|
190 | Perl release, if B<--center> is not also given.
|
---|
191 |
|
---|
192 | =item B<-q> I<quotes>, B<--quotes>=I<quotes>
|
---|
193 |
|
---|
194 | Sets the quote marks used to surround CE<lt>> text to I<quotes>. If
|
---|
195 | I<quotes> is a single character, it is used as both the left and right
|
---|
196 | quote; if I<quotes> is two characters, the first character is used as the
|
---|
197 | left quote and the second as the right quoted; and if I<quotes> is four
|
---|
198 | characters, the first two are used as the left quote and the second two as
|
---|
199 | the right quote.
|
---|
200 |
|
---|
201 | I<quotes> may also be set to the special value C<none>, in which case no
|
---|
202 | quote marks are added around CE<lt>> text (but the font is still changed for
|
---|
203 | troff output).
|
---|
204 |
|
---|
205 | =item B<-r>, B<--release>
|
---|
206 |
|
---|
207 | Set the centered footer. By default, this is the version of Perl you run
|
---|
208 | B<pod2man> under. Note that some system an macro sets assume that the
|
---|
209 | centered footer will be a modification date and will prepend something like
|
---|
210 | "Last modified: "; if this is the case, you may want to set B<--release> to
|
---|
211 | the last modified date and B<--date> to the version number.
|
---|
212 |
|
---|
213 | =item B<-s>, B<--section>
|
---|
214 |
|
---|
215 | Set the section for the C<.TH> macro. The standard section numbering
|
---|
216 | convention is to use 1 for user commands, 2 for system calls, 3 for
|
---|
217 | functions, 4 for devices, 5 for file formats, 6 for games, 7 for
|
---|
218 | miscellaneous information, and 8 for administrator commands. There is a lot
|
---|
219 | of variation here, however; some systems (like Solaris) use 4 for file
|
---|
220 | formats, 5 for miscellaneous information, and 7 for devices. Still others
|
---|
221 | use 1m instead of 8, or some mix of both. About the only section numbers
|
---|
222 | that are reliably consistent are 1, 2, and 3.
|
---|
223 |
|
---|
224 | By default, section 1 will be used unless the file ends in .pm in which case
|
---|
225 | section 3 will be selected.
|
---|
226 |
|
---|
227 | =item B<-v>, B<--verbose>
|
---|
228 |
|
---|
229 | Print out the name of each output file as it is being generated.
|
---|
230 |
|
---|
231 | =back
|
---|
232 |
|
---|
233 | =head1 DIAGNOSTICS
|
---|
234 |
|
---|
235 | If B<pod2man> fails with errors, see L<Pod::Man> and L<Pod::Parser> for
|
---|
236 | information about what those errors might mean.
|
---|
237 |
|
---|
238 | =head1 EXAMPLES
|
---|
239 |
|
---|
240 | pod2man program > program.1
|
---|
241 | pod2man SomeModule.pm /usr/perl/man/man3/SomeModule.3
|
---|
242 | pod2man --section=7 note.pod > note.7
|
---|
243 |
|
---|
244 | If you would like to print out a lot of man page continuously, you probably
|
---|
245 | want to set the C and D registers to set contiguous page numbering and
|
---|
246 | even/odd paging, at least on some versions of man(7).
|
---|
247 |
|
---|
248 | troff -man -rC1 -rD1 perl.1 perldata.1 perlsyn.1 ...
|
---|
249 |
|
---|
250 | To get index entries on stderr, turn on the F register, as in:
|
---|
251 |
|
---|
252 | troff -man -rF1 perl.1
|
---|
253 |
|
---|
254 | The indexing merely outputs messages via C<.tm> for each major page,
|
---|
255 | section, subsection, item, and any C<XE<lt>E<gt>> directives. See
|
---|
256 | L<Pod::Man> for more details.
|
---|
257 |
|
---|
258 | =head1 BUGS
|
---|
259 |
|
---|
260 | Lots of this documentation is duplicated from L<Pod::Man>.
|
---|
261 |
|
---|
262 | =head1 NOTES
|
---|
263 |
|
---|
264 | For those not sure of the proper layout of a man page, here are some notes
|
---|
265 | on writing a proper man page.
|
---|
266 |
|
---|
267 | The name of the program being documented is conventionally written in bold
|
---|
268 | (using BE<lt>E<gt>) wherever it occurs, as are all program options.
|
---|
269 | Arguments should be written in italics (IE<lt>E<gt>). Functions are
|
---|
270 | traditionally written in italics; if you write a function as function(),
|
---|
271 | Pod::Man will take care of this for you. Literal code or commands should
|
---|
272 | be in CE<lt>E<gt>. References to other man pages should be in the form
|
---|
273 | C<manpage(section)>, and Pod::Man will automatically format those
|
---|
274 | appropriately. As an exception, it's traditional not to use this form when
|
---|
275 | referring to module documentation; use C<LE<lt>Module::NameE<gt>> instead.
|
---|
276 |
|
---|
277 | References to other programs or functions are normally in the form of man
|
---|
278 | page references so that cross-referencing tools can provide the user with
|
---|
279 | links and the like. It's possible to overdo this, though, so be careful not
|
---|
280 | to clutter your documentation with too much markup.
|
---|
281 |
|
---|
282 | The major headers should be set out using a C<=head1> directive, and are
|
---|
283 | historically written in the rather startling ALL UPPER CASE format, although
|
---|
284 | this is not mandatory. Minor headers may be included using C<=head2>, and
|
---|
285 | are typically in mixed case.
|
---|
286 |
|
---|
287 | The standard sections of a manual page are:
|
---|
288 |
|
---|
289 | =over 4
|
---|
290 |
|
---|
291 | =item NAME
|
---|
292 |
|
---|
293 | Mandatory section; should be a comma-separated list of programs or functions
|
---|
294 | documented by this podpage, such as:
|
---|
295 |
|
---|
296 | foo, bar - programs to do something
|
---|
297 |
|
---|
298 | Manual page indexers are often extremely picky about the format of this
|
---|
299 | section, so don't put anything in it except this line. A single dash, and
|
---|
300 | only a single dash, should separate the list of programs or functions from
|
---|
301 | the description. Functions should not be qualified with C<()> or the like.
|
---|
302 | The description should ideally fit on a single line, even if a man program
|
---|
303 | replaces the dash with a few tabs.
|
---|
304 |
|
---|
305 | =item SYNOPSIS
|
---|
306 |
|
---|
307 | A short usage summary for programs and functions. This section is mandatory
|
---|
308 | for section 3 pages.
|
---|
309 |
|
---|
310 | =item DESCRIPTION
|
---|
311 |
|
---|
312 | Extended description and discussion of the program or functions, or the body
|
---|
313 | of the documentation for man pages that document something else. If
|
---|
314 | particularly long, it's a good idea to break this up into subsections
|
---|
315 | C<=head2> directives like:
|
---|
316 |
|
---|
317 | =head2 Normal Usage
|
---|
318 |
|
---|
319 | =head2 Advanced Features
|
---|
320 |
|
---|
321 | =head2 Writing Configuration Files
|
---|
322 |
|
---|
323 | or whatever is appropriate for your documentation.
|
---|
324 |
|
---|
325 | =item OPTIONS
|
---|
326 |
|
---|
327 | Detailed description of each of the command-line options taken by the
|
---|
328 | program. This should be separate from the description for the use of things
|
---|
329 | like L<Pod::Usage|Pod::Usage>. This is normally presented as a list, with
|
---|
330 | each option as a separate C<=item>. The specific option string should be
|
---|
331 | enclosed in BE<lt>E<gt>. Any values that the option takes should be
|
---|
332 | enclosed in IE<lt>E<gt>. For example, the section for the option
|
---|
333 | B<--section>=I<manext> would be introduced with:
|
---|
334 |
|
---|
335 | =item B<--section>=I<manext>
|
---|
336 |
|
---|
337 | Synonymous options (like both the short and long forms) are separated by a
|
---|
338 | comma and a space on the same C<=item> line, or optionally listed as their
|
---|
339 | own item with a reference to the canonical name. For example, since
|
---|
340 | B<--section> can also be written as B<-s>, the above would be:
|
---|
341 |
|
---|
342 | =item B<-s> I<manext>, B<--section>=I<manext>
|
---|
343 |
|
---|
344 | (Writing the short option first is arguably easier to read, since the long
|
---|
345 | option is long enough to draw the eye to it anyway and the short option can
|
---|
346 | otherwise get lost in visual noise.)
|
---|
347 |
|
---|
348 | =item RETURN VALUE
|
---|
349 |
|
---|
350 | What the program or function returns, if successful. This section can be
|
---|
351 | omitted for programs whose precise exit codes aren't important, provided
|
---|
352 | they return 0 on success as is standard. It should always be present for
|
---|
353 | functions.
|
---|
354 |
|
---|
355 | =item ERRORS
|
---|
356 |
|
---|
357 | Exceptions, error return codes, exit statuses, and errno settings.
|
---|
358 | Typically used for function documentation; program documentation uses
|
---|
359 | DIAGNOSTICS instead. The general rule of thumb is that errors printed to
|
---|
360 | STDOUT or STDERR and intended for the end user are documented in DIAGNOSTICS
|
---|
361 | while errors passed internal to the calling program and intended for other
|
---|
362 | programmers are documented in ERRORS. When documenting a function that sets
|
---|
363 | errno, a full list of the possible errno values should be given here.
|
---|
364 |
|
---|
365 | =item DIAGNOSTICS
|
---|
366 |
|
---|
367 | All possible messages the program can print out--and what they mean. You
|
---|
368 | may wish to follow the same documentation style as the Perl documentation;
|
---|
369 | see perldiag(1) for more details (and look at the POD source as well).
|
---|
370 |
|
---|
371 | If applicable, please include details on what the user should do to correct
|
---|
372 | the error; documenting an error as indicating "the input buffer is too
|
---|
373 | small" without telling the user how to increase the size of the input buffer
|
---|
374 | (or at least telling them that it isn't possible) aren't very useful.
|
---|
375 |
|
---|
376 | =item EXAMPLES
|
---|
377 |
|
---|
378 | Give some example uses of the program or function. Don't skimp; users often
|
---|
379 | find this the most useful part of the documentation. The examples are
|
---|
380 | generally given as verbatim paragraphs.
|
---|
381 |
|
---|
382 | Don't just present an example without explaining what it does. Adding a
|
---|
383 | short paragraph saying what the example will do can increase the value of
|
---|
384 | the example immensely.
|
---|
385 |
|
---|
386 | =item ENVIRONMENT
|
---|
387 |
|
---|
388 | Environment variables that the program cares about, normally presented as a
|
---|
389 | list using C<=over>, C<=item>, and C<=back>. For example:
|
---|
390 |
|
---|
391 | =over 6
|
---|
392 |
|
---|
393 | =item HOME
|
---|
394 |
|
---|
395 | Used to determine the user's home directory. F<.foorc> in this
|
---|
396 | directory is read for configuration details, if it exists.
|
---|
397 |
|
---|
398 | =back
|
---|
399 |
|
---|
400 | Since environment variables are normally in all uppercase, no additional
|
---|
401 | special formatting is generally needed; they're glaring enough as it is.
|
---|
402 |
|
---|
403 | =item FILES
|
---|
404 |
|
---|
405 | All files used by the program or function, normally presented as a list, and
|
---|
406 | what it uses them for. File names should be enclosed in FE<lt>E<gt>. It's
|
---|
407 | particularly important to document files that will be potentially modified.
|
---|
408 |
|
---|
409 | =item CAVEATS
|
---|
410 |
|
---|
411 | Things to take special care with, sometimes called WARNINGS.
|
---|
412 |
|
---|
413 | =item BUGS
|
---|
414 |
|
---|
415 | Things that are broken or just don't work quite right.
|
---|
416 |
|
---|
417 | =item RESTRICTIONS
|
---|
418 |
|
---|
419 | Bugs you don't plan to fix. :-)
|
---|
420 |
|
---|
421 | =item NOTES
|
---|
422 |
|
---|
423 | Miscellaneous commentary.
|
---|
424 |
|
---|
425 | =item SEE ALSO
|
---|
426 |
|
---|
427 | Other man pages to check out, like man(1), man(7), makewhatis(8), or
|
---|
428 | catman(8). Normally a simple list of man pages separated by commas, or a
|
---|
429 | paragraph giving the name of a reference work. Man page references, if they
|
---|
430 | use the standard C<name(section)> form, don't have to be enclosed in
|
---|
431 | LE<lt>E<gt> (although it's recommended), but other things in this section
|
---|
432 | probably should be when appropriate.
|
---|
433 |
|
---|
434 | If the package has a mailing list, include a URL or subscription
|
---|
435 | instructions here.
|
---|
436 |
|
---|
437 | If the package has a web site, include a URL here.
|
---|
438 |
|
---|
439 | =item AUTHOR
|
---|
440 |
|
---|
441 | Who wrote it (use AUTHORS for multiple people). Including your current
|
---|
442 | e-mail address (or some e-mail address to which bug reports should be sent)
|
---|
443 | so that users have a way of contacting you is a good idea. Remember that
|
---|
444 | program documentation tends to roam the wild for far longer than you expect
|
---|
445 | and pick an e-mail address that's likely to last if possible.
|
---|
446 |
|
---|
447 | =item COPYRIGHT AND LICENSE
|
---|
448 |
|
---|
449 | For copyright
|
---|
450 |
|
---|
451 | Copyright YEAR(s) by YOUR NAME(s)
|
---|
452 |
|
---|
453 | (No, (C) is not needed. No, "all rights reserved" is not needed.)
|
---|
454 |
|
---|
455 | For licensing the easiest way is to use the same licensing as Perl itself:
|
---|
456 |
|
---|
457 | This library is free software; you may redistribute it and/or modify
|
---|
458 | it under the same terms as Perl itself.
|
---|
459 |
|
---|
460 | This makes it easy for people to use your module with Perl. Note that
|
---|
461 | this licensing is neither an endorsement or a requirement, you are of
|
---|
462 | course free to choose any licensing.
|
---|
463 |
|
---|
464 | =item HISTORY
|
---|
465 |
|
---|
466 | Programs derived from other sources sometimes have this, or you might keep
|
---|
467 | a modification log here. If the log gets overly long or detailed,
|
---|
468 | consider maintaining it in a separate file, though.
|
---|
469 |
|
---|
470 | =back
|
---|
471 |
|
---|
472 | In addition, some systems use CONFORMING TO to note conformance to relevant
|
---|
473 | standards and MT-LEVEL to note safeness for use in threaded programs or
|
---|
474 | signal handlers. These headings are primarily useful when documenting parts
|
---|
475 | of a C library. Documentation of object-oriented libraries or modules may
|
---|
476 | use CONSTRUCTORS and METHODS sections for detailed documentation of the
|
---|
477 | parts of the library and save the DESCRIPTION section for an overview; other
|
---|
478 | large modules may use FUNCTIONS for similar reasons. Some people use
|
---|
479 | OVERVIEW to summarize the description if it's quite long.
|
---|
480 |
|
---|
481 | Section ordering varies, although NAME should I<always> be the first section
|
---|
482 | (you'll break some man page systems otherwise), and NAME, SYNOPSIS,
|
---|
483 | DESCRIPTION, and OPTIONS generally always occur first and in that order if
|
---|
484 | present. In general, SEE ALSO, AUTHOR, and similar material should be left
|
---|
485 | for last. Some systems also move WARNINGS and NOTES to last. The order
|
---|
486 | given above should be reasonable for most purposes.
|
---|
487 |
|
---|
488 | Finally, as a general note, try not to use an excessive amount of markup.
|
---|
489 | As documented here and in L<Pod::Man>, you can safely leave Perl variables,
|
---|
490 | function names, man page references, and the like unadorned by markup and
|
---|
491 | the POD translators will figure it out for you. This makes it much easier
|
---|
492 | to later edit the documentation. Note that many existing translators
|
---|
493 | (including this one currently) will do the wrong thing with e-mail addresses
|
---|
494 | or URLs when wrapped in LE<lt>E<gt>, so don't do that.
|
---|
495 |
|
---|
496 | For additional information that may be more accurate for your specific
|
---|
497 | system, see either L<man(5)> or L<man(7)> depending on your system manual
|
---|
498 | section numbering conventions.
|
---|
499 |
|
---|
500 | =head1 SEE ALSO
|
---|
501 |
|
---|
502 | L<Pod::Man>, L<Pod::Parser>, L<man(1)>, L<nroff(1)>, L<podchecker(1)>,
|
---|
503 | L<troff(1)>, L<man(7)>
|
---|
504 |
|
---|
505 | The man page documenting the an macro set may be L<man(5)> instead of
|
---|
506 | L<man(7)> on your system.
|
---|
507 |
|
---|
508 | The current version of this script is always available from its web site at
|
---|
509 | L<http://www.eyrie.org/~eagle/software/podlators/>. It is also part of the
|
---|
510 | Perl core distribution as of 5.6.0.
|
---|
511 |
|
---|
512 | =head1 AUTHOR
|
---|
513 |
|
---|
514 | Russ Allbery <[email protected]>, based I<very> heavily on the original
|
---|
515 | B<pod2man> by Larry Wall and Tom Christiansen. Large portions of this
|
---|
516 | documentation, particularly the sections on the anatomy of a proper man
|
---|
517 | page, are taken from the B<pod2man> documentation by Tom.
|
---|
518 |
|
---|
519 | =head1 COPYRIGHT AND LICENSE
|
---|
520 |
|
---|
521 | Copyright 1999, 2000, 2001 by Russ Allbery <[email protected]>.
|
---|
522 |
|
---|
523 | This program is free software; you may redistribute it and/or modify it
|
---|
524 | under the same terms as Perl itself.
|
---|
525 |
|
---|
526 | =cut
|
---|
527 |
|
---|
528 | __END__
|
---|
529 | :endofperl
|
---|