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