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