| 1 | #!/import/archperf/ws/devtools/4/v9/bin/perl |
| 2 | eval 'exec /import/archperf/ws/devtools/4/v9/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 |