This is Info file pm.info, produced by Makeinfo version 1.68 from the
input file bigpm.texi.
File: pm.info, Node: Getopt/EvaP, Next: Getopt/ExPar, Prev: Getopt/Declare, Up: Module List
evaluate Perl command line parameters.
**************************************
NAME
====
Getopt::EvaP - evaluate Perl command line parameters.
SYNOPSIS
========
use vars qw/@PDT @MM %OPT/;
use Getopt::EvaP;
EvaP \@PDT, \@MM, \%OPT;
EXPORT
======
`use Getopt::EvaP' exports the subs `EvaP' and `EvaP_PAC' into your
name space.
DESCRIPTION
===========
*@PDT* is the Parameter Description Table, which is a reference to a
list of strings describing the command line parameters, aliases, types and
default values. *@MM* is the Message Module, which is also a reference to
a list of strings describing the command and it's parameters. *%OPT* is
an optional hash reference where Evaluate Parameters should place its
results. If specified, the historical behaviour of modifying the calling
routines' namespace by storing option values in *%Options*, %options and
*$opt** is disabled.
Introduction
------------
Function Evaluate Parameters parses a Perl command line in a simple and
consistent manner, performs type checking of parameter values, and provides
the user with first-level help. Evaluate Parameters is also embeddable in
your application; refer to the *evap_pac(2)* man page for complete details.
Evaluate Parameters handles command lines in the following format:
command [-parameters] [file_list]
where parameters and file_list are all optional. A typical example is
the C compiler:
cc -O -o chunk chunk.c
In this case there are two parameters and a file_list consisting of a
single file name for the cc command.
Parameter Description Table (PDT) Syntax
----------------------------------------
Here is the PDT syntax. Optional constructs are enclosed in [], and the
| character separates possible values in a list.
PDT [program_name, alias]
[parameter_name[, alias]: type [ = [default_variable,] default_value]]
PDTEND [optional_file_list | required_file_list | no_file_list]
So, the simplest possible PDT would be:
PDT
PDTEND
This PDT would simply define a *-help* switch for the command, but is
rather useless.
A typical PDT would look more like this:
PDT frog
number, n: integer = 1
PDTEND no_file_list
This PDT, for command frog, defines a single parameter, number (or n),
of type integer with a default value of 1. The PDTEND *no_file_list*
indicator indicates that no trailing file_list can appear on the command
line. Of course, the *-help* switch is defined automatically.
The *default_variable* is an environment variable - see the section
Usage Notes for complete details.
Usage Notes
-----------
Usage is similar to getopt/getopts/newgetopt: define a Parameter
Description Table declaring a list of command line parameters, their
aliases, types and default values. The command line parameter *-help*
(alias -h) is automatically included by Evaluate Parameters. After the
evaluation the values of the command line parameters are stored in
variable names of the form *$opt_parameter*, except for lists which are
returned as *@opt_parameter*, where parameter is the full spelling of the
command line parameter. NOTE: values are also returned in the hashes
%options and *%Options*, with lists being passed as a reference to a list.
Of course, you can specify where you want Evaluate Parameters to return
its results, in which case this historical feature of writing into your
namespace is disabled.
An optional PDT line can be included that tells Evaluate Parameters
whether or not trailing file names can appear on the command line after
all the parameters. It can read *no_file_list*, *optional_file_list* or
*required_file_list* and, if not specified, defaults to optional. Although
placement is not important, this line is by convention the last line of the
PDT declaration.
Additionally a Message Module is declared that describes the command
and provides examples. Following the main help text an optional series of
help text messages can be specified for individual command line
parameters. In the following sample program all the parameters have this
additional text which describes that parameter's type. The leadin
character is a dot in column one followed by the full spelling of the
command line parameter. Use *-full_help* rather than *-help* to see this
supplemental information. This sample program illustrates the various
types and how to use *EvaP()*. The key type is a special type that
enumerates valid values for the command line parameter. The boolean type
may be specified as TRUE/FALSE, YES/NO, ON/OFF or 1/0. Parameters of type
file have ~ and $HOME expanded, and default values stdin and stdout
converted to `-' and `>-', respectively. Of special note is the default
value *$required*: when specified, Evaluate Parameters will ensure a value
is specified for that command line parameter.
All types except switch may be *list of*, like the tty parameter below.
A list parameter can be specified multiple times on the command line.
NOTE: in general you should ALWAYS quote components of your lists, even if
they're not type string, since Evaluate Parameters uses eval to parse them.
Doing this prevents eval from evaluating expressions that it shouldn't,
such as file name shortcuts like $HOME, and backticked items like
`hostname`. Although the resulting PDT looks cluttered, Evaluate
Parameters knows what to do and eliminates superfluous quotes
appropriately.
Finally, you can specify a default value via an environment variable.
If a command line parameter is not specified and there is a corresponding
environment variable defined then Evaluate Parameters will use the value
of the environment variable. Examine the command parameter for the syntax.
With this feature users can easily customize command parameters to their
liking. Although the name of the environment variable can be whatever you
choose, the following scheme is suggested for consistency and to avoid
conflicts in names:
* Use all uppercase characters.
* Begin the variable name with D_, to suggest a default variable.
* Continue with the name of the command or its alias followed by an
underscore.
* Complete the variable name with the name of the parameter or its
alias.
So, for example, D_DISCI_DO would name a default variable for the
display_option (do) parameter of the display_command_information (disci)
command. Works for MS-DOS and Unix.
Example
=======
#!/usr/local/bin/perl
use Getopt::EvaP;
@PDT = split /\n/, <<'end-of-PDT';
PDT sample
verbose, v: switch
command, c: string = D_SAMPLE_COMMAND, "ps -el"
scale_factor, sf: real = 1.2340896e-1
millisecond_update_interval, mui: integer = $required
ignore_output_file_column_one, iofco: boolean = TRUE
output, o: file = stdout
queue, q: key plotter, postscript, text, printer, keyend = printer
destination, d: application = `hostname`
tty, t: list of name = ("/dev/console", "/dev/tty0", "/dev/tty1")
PDTEND optional_file_list
end-of-PDT
@MM = split /\n/, <<'end-of-MM';
sample
A sample program demonstrating typical Evaluate Parameters
usage.
Examples:
sample
sample -usage_help
sample -help
sample -full_help
sample -mui 1234
.verbose
A switch type parameter emulates a typical standalone
switch. If the switch is specified Evaluate Parameters
returns a '1'.
.command
A string type parameter is just a list of characters,
which must be quoted if it contains whitespace.
NOTE: for this parameter you can also create and
initialize the environment variable D_SAMPLE_COMMAND to
override the standard default value for this command
line parameter. All types except switch may have a
default environment variable for easy user customization.
.scale_factor
A real type parameter must be a real number that may
contain a leading sign, a decimal point and an exponent.
.millisecond_update_interval
An integer type parameter must consist of all digits
with an optional leading sign. NOTE: this parameter's
default value is $required, meaning that
Evaluate Parameters ensures that this parameter is
specified and given a valid value. All types except
switch may have a default value of $required.
.ignore_output_file_column_one
A boolean type parameter may be TRUE/YES/ON/1 or
FALSE/NO/OFF/0, either upper or lower case. If TRUE,
Evaluate Parameters returns a value of '1', else '0'.
.output
A file type parameter expects a filename. For Unix
$HOME and ~ are expanded. For EvaP/Perl stdin and
stdout are converted to '-' and '>-' so they can be
used in a Perl open() function.
.queue
A key type parameter enumerates valid values. Only the
specified keywords can be entered on the command line.
.destination
An application type parameter is not type-checked in
any - the treatment of this type of parameter is
application specific. NOTE: this parameter' default
value is enclosed in grave accents (or "backticks").
Evaluate Parameters executes the command and uses it's
standard output as the default value for the parameter.
.tty
A name type parameter is similar to a string except
that embedded white-space is not allowed. NOTE: this
parameter is also a LIST, meaning that it can be
specified multiple times and that each value is pushed
onto a Perl LIST variable. In general you should quote
all list elements. All types except switch may be
'list of'.
end-of-MM
EvaP \@PDT, \@MM; # evaluate parameters
print "\nProgram name:\n $Options{'help'}\n\n";
if (defined $Options{'verbose'}) {print "\nverbose = $Options{'verbose'}\n";}
print "command = \"$Options{'command'}\"\n";
print "scale_factor = $Options{'scale_factor'}\n";
print "millisecond_update_interval = $Options{'millisecond_update_interval'}\n";
print "ignore_output_file_column_one = $Options{'ignore_output_file_column_one'}\n";
print "output = $Options{'output'}\n";
print "queue = $Options{'queue'}\n";
print "destination = $Options{'destination'}\n";
print "'list of' tty = \"", join('", "', @{$Options{'tty'}}), "\"\n";
print "\nFile names:\n ", join ' ', @ARGV, "\n" if @ARGV;
Using the PDT as a guide, Evaluate Parameters parses a user's command
line, returning the results of the evaluation to global variables of the
form *$opt_parameter*, *@opt_parameter*, *%Options{'parameter'}* or
*%options{'parameter'}*, where parameter is the full spelling of the
command line parameter.
Of course, you can specify where you want Evaluate Parameters to return
its results, in which case this historical feature of writing into your
namespace is disabled.
Every command using Evaluate Parameters automatically has a *-help*
switch which displays parameter help; no special code is required in your
application.
Customization of EvaP's Help Output
-----------------------------------
There are several Help Hook strings that can be altered to customize
*EvaP*'s help output. Currently there is only one general area that can
be customized: usage and error text dealing with the trailing file_list.
For instance, if a command requires one or more trailing file names after
all the command line switches, the default *-help* text is:
file(s) required by this command
Some commands do not want trailing "file names", but rather some other
type of information. An example is *display_command_information* where a
single Program_Name is expected. The following code snippet shows how to
do this:
$Getopt::EvaP::evap_Help_Hooks{'P_HHURFL'} = " Program_Name\n";
$Getopt::EvaP::evap_Help_Hooks{'P_HHBRFL'} =
"\nA Program_Name is required by this command.\n\n";
$Getopt::EvaP::evap_Help_Hooks{'P_HHERFL'} =
"A trailing Program_Name is required by this command.\n";
EvaP \@PDT, \@MM;
As you can see, the hash *%evap_Help_Hooks* is indexed by a simple
ordinal. The ordinals are shown below and are mostly self-explanatory.
In case you don't have access to the source for Evaluate Parameters, here
are the default values of the Help Hook strings.
$Getopt::EvaP:evap_Help_Hooks{'P_HHURFL'} = " file(s)\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHUOFL'} = " [file(s)]\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHUNFL'} = "\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHBRFL'} =
"\nfile(s) required by this command\n\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHBOFL'} =
"\n[file(s)] optionally required by this command\n\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHBNFL'} = "\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHERFL'} =
"Trailing file name(s) required.\n";
$Getopt::EvaP:evap_Help_Hooks{'P_HHENFL'} =
"Trailing file name(s) not permitted.\n";
The Help Hooks naming convention is rather simple:
P_HHtf
where:
P_HH implies an Evaluate Parameters Help Hook
t type:
U=Usage Help
B=Brief and Full Help
E=error message
f file_list:
RFL=required_file_list
OFL=optional_file_list
NFL=no_file_list
Note to *genPerlTk* and *genTclTk* users: using these Help Hooks may
cause the "genTk programs" to generate an unuseable Tk script. This
happens because the "genTk programs" look for the strings "required by
this command" or "optionally required by this command" in order to
generate the file_list Entry widget - if these string are missing the
widget is not created. An easy solution is to ensure that your Help Hook
text contains said string, just like the code snippet above; otherwise you
must manually add the required Tk code yourself.
Human Interface Guidelines
--------------------------
To make Evaluate Parameters successful, you, the application developer,
must follow certain conventions when choosing parameter names and aliases.
Parameter names consist of one or more words, separated by underscores,
and describe the parameter (for example, verbose and *spool_directory*).
You can abbreviate parameters: use the first letter of each word in the
parameter name. Do not use underscores. For example, you can abbreviate
command as c and *delay_period* as *dp*.
There are exceptions to this standard:
* password is abbreviated *pw*.
* The words minimum and maximum are abbreviated min and max. So, the
abbreviation for the parameter *maximum_byte_count* is *maxbc*.
* There are no abbreviations for the parameters *usage_help* and
*full_help*; I do not want to prevent *uh* and fh from being used as
valid command line parameters.
Variables MANPAGER, PAGER and D_EVAP_DO_PAGE
--------------------------------------------
The environment variable MANPAGER (or PAGER) is used to control the
display of help information generated by Evaluate Parameters. If defined
and non-null, the value of the environment variable is taken as the name
of the program to pipe the help output through. If no paging program is
defined then the program more is used.
The boolean environment variable D_EVAP_DO_PAGE can be set to
FALSE/NO/OFF/0, any case, to disable this automatic paging feature (or you
can set your paging program to cat).
Return Values
-------------
*EvaP()* behaves differently depending upon whether it's called to
parse an application's command line, or as an embedded command line parser
(for instance, when using *evap_pac()*).
Application Embedded
Command Line Command Line
----------------------------------------
error exit(1) return(0)
success return(1) return(1)
help exit(0) return(-1)
SEE ALSO
========
evap(2)
evap.c(2)
EvaP.pm(2)
evap.tcl(2)
evap_pac(2)
addmm, add_message_modules(1)
disci, display_command_information(1)
genmp, generate_man_page(1)
genpdt, generate_pdt(1)
genPerlTk, generate_PerlTk_program(1)
genTclTk, generate_TclTk_program(1)
All available from directory F.
BUGS
====
The code is messy (written in Perl4-ese), and should be redone, but I
can't rationalize the time expenditure for code that still works so well.
AUTHOR
======
Stephen.O.Lidie@Lehigh.EDU
HISTORY
=======
lusol@Lehigh.EDU 94/10/28 (PDT version 2.0) Version 2.2
. Original release - derived from evap.pl version 2.1.
. Undef option values for subsequent embedded calls.
lusol@Lehigh.EDU 95/10/27 (PDT version 2.0) Version 2.3.0
. Be a strict as possible.
. Revert to -h alias rather than -?. (-? -?? -??? still available.)
. Move into Getopt class.
. Format for 80 columns (mostly).
. Optional third argument on EvaP call can be a reference to your own
%Options hash. If specified, the variabes %Options, %options and
$opt* are not used.
lusol@Lehigh.EDU 97/01/12 (PDT version 2.0) Version 2.3.1
. Fix Makefile.PL so it behaves properly. Convert nroff man data to pod
format.
Stephen.O.Lidie@Lehigh.EDU 98/01/14 (PDT version 2.0) Version 2.3.2
. Incorporate Achim Bohnet's POD patch while updating for Win32.
Stephen.O.Lidie@Lehigh.EDU 98/07/25 (PDT version 2.0) Version 2.3.3
. Update Makefile.PL so it works in the standard fashion.
. Update for perl 5.005 and Tk 800.008.
. Remove use of ENGLISH.
. Add genpTk to generate a Perl/TK GUI wrapper around command line
programs. Primarily for users of EvaP(), can be used by other codes
as well.
Stephen.O.Lidie@Lehigh.EDU 99/04/03 (PDT version 2.0) Version 2.3.5
. Update Makefile.PL for ActiveState, fix a -w message found by 5.005_03.
COPYRIGHT
=========
Copyright (C) 1993 - 1999 Stephen O. Lidie. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the same terms as Perl itself.
File: pm.info, Node: Getopt/ExPar, Next: Getopt/Long, Prev: Getopt/EvaP, Up: Module List
Extended Parameters command line parser.
****************************************
NAME
====
Getopt::ExPar - Extended Parameters command line parser.
SYNOPSIS
========
use Getopt::ExPar;
my(@PDT, @MM, %OPT);
ExPar \@PDT, \@MM, $OPT;
EXPORT
======
`use Getopt::ExPar' exports the sub `ExPar' into your name space.
DESCRIPTION
===========
*ExPar* is a *perl5* module used to parse command line parameters.
This package uses the *@PDT*, Parameter Description Table, and the *@MM*,
Message Module, to return *%OPT* which is a hash reference containing the
command line option data. The function of *Getopt::ExPar* is based on
*Getopt::EvaP*, created by Stephen O. Lidie.
Introduction
------------
The ExPar function parses a perl command line. Using the option
definitions in the *@PDT*, argument types are checked and the arguments
themselves may be checked against a specified range or pattern. By using
both *@PDT* and *@MM*, several types of help may be retured to the user.
ExPar handles command lines with this format:
command [-parameters] [file_list]
where any parameters and file_list are optional.
Parameter Description Table (PDT) Syntax
----------------------------------------
Here is the PDT syntax. Optional constructs are enclosed in [], and the
| character separates possible values in a list.
PDT [program_name, alias]
[parameter_name[, alias]: type [pattern | range] [ = [default_variable,] default_value]]
PDTEND [flag_list]
*flag_list* is one or more of the following flags:
*optional_file_list* | *required_file_list* | *no_file_list*:
specifies condition of list of files at end of command line. (only
one of these may be specified) abbreviations: allows for abbreviations
of commands or aliases as long as enough of the command is given to
make it distinguishable from all others. If not, a message is printed
so the user may be more specific. *switchglomming*: allows for multiple
single-letter switch options to be specified as single option (must be
first option). *pdt_warnings*: for debugging a *@PDT*, it prints out
messages that are not necessarily errors, like inconsistent number of
default values in a list, etc.
The *default_variable* is an environment variable - see the section
Usage Notes for complete details.
So, the simplest possible PDT would be:
PDT
PDTEND
This PDT would simply define a *-help* switch for the command, but is
rather useless.
A typical PDT would look more like this:
PDT frog
number, n: integer = 1
chars, c: string = "default_string"
PDTEND no_file_list
This PDT, for command frog, defines two parameters, number (or n), of
type integer with a default value of 1, and chars (or c), of type string
with a default value of "default_string". The PDTEND *no_file_list*
indicator indicates that no trailing file_list can appear on the command
line. Of course, the *-help* switch is defined automatically.
Each of these options may be further refined by using a range and a
pattern, respectively:
PDT frog
number, n: integer (((#<5) and (#%2==1)), ((#<20) and (#%2==0)), >100) = 1
chars, c: string ('default_(optional_)?string') = "default_string"
PDTEND no_file_list
Here, a range is given for the number parameter. This is a list of perl
conditional statements, separated with commas. Each element in the list is
ORed together to construct a single condition with which the parameter
value is tested. The '#' is substituted with the actual value, '1' in
this instance. For simple conditions like '>100', the '#' is implied.
Other simple conditions are '<' and '==' (a single '=' is accepted as
'==', not an assignment). Ex: This condition: (#>10, #<-10, #==5,
#=3, -5 < # <= 2) Can be reduced to: (>10, <-10, 5, 3, -5<#<=2)
Notice that the compound condition, '-5<#<=2', MUST contain the '#'.
As for the 'number' parameter above, the range (or condition) is
translated as: (Less than 5 AND odd) OR (Less than 20 AND even) OR
(Greater than 100) So, '1' fits this condition. These conditions may be
as complex as you wish. ENV variables may also be referenced within these
range specifications.
The pattern is a perl regular expression with which the value, in this
case "default_string", is tested.
Usage Notes
-----------
Currently, both *@PDT* and *@MM* are required, as is a reference to a
hash into which all parameter values are placed. A call to ExPar *must*
have this form:
ExPar(\@PDT, \@MM, \%OPT);
An optional PDT flag can be included that tells ExPar whether or not
trailing file names can appear on the command line after all the
parameters. It can read *no_file_list*, *optional_file_list* or
*required_file_list* and, if not specified, defaults to optional. Any
flags *must* be on the PDTEND line, which is the last line of the *@PDT*
array. Other flags include *switchglomming* and *pdt_warnings*.
The *switchglomming* flag allows multiple single-letter switch
parameters to be specified as a single parameter. Either the option name
or its alias must be a single letter to be used in the switch glom. Ex:
script.pl -x -f -c -a arga --> script.pl -xfc -a arga The switch glo
*must* be the first option on the command line. Note: this can be changed
if heavily requested.
Additionally a Message Module is declared that describes the command
and provides examples. Following the main help text an optional series of
help text messages can be specified for individual command line
parameters. In the following sample program all the parameters have this
additional text which describes that type of parameter. The leadin
character is a dot in column one followed by the full spelling of the
command line parameter. Use *-full_help* rather than *-help* to see this
supplemental information. This sample program illustrates the various
types and how to use *ExPar()*. The key type is a special type that
enumerates valid values for the command line parameter. The boolean type
may be specified as TRUE/FALSE, YES/NO, ON/OFF or 1/0. Parameters of type
file have ~ and $HOME expanded, and default values stdin and stdout
converted to '-' and '>-', respectively. Of special note is the default
value *$required*: when specified, ExPar will ensure a value is specified
for that command line parameter.
All types except switch may be *list of*, like the *real70* parameter
below. A list parameter can be specified multiple times on the command
line. NOTE: in general you should ALWAYS quote components of your lists,
even if they are not type string, since Evaluate Parameters uses eval to
parse them. Doing this prevents eval from evaluating expressions that it
should not, such as file name shortcuts like $HOME, and backticked items
like `hostname`. Although the resulting PDT looks cluttered, Evaluate
Parameters knows what to do and eliminates superfluous quotes
appropriately.
Finally, you can specify a default value via an environment variable.
If a command line parameter is not specified and there is a corresponding
environment variable defined then Evaluate Parameters will use the value
of the environment variable. Examine the command parameter for the syntax.
With this feature users can easily customize command parameters to their
liking. Although the name of the environment variable can be whatever you
choose, the following scheme is suggested for consistency and to avoid
conflicts in names:
EXAMPLE
=======
@PDT = split /\n/, <<'end-of-PDT'; PDT expar_test switch01, sw01 :
switch integer13, int13 : integer (5 < # <= 9) = 7 real70 : list of
real = ENV:D_real70, (45, 54) boolean07, bo07 : list of boolean = (1,
"true") string17 : list of string ('s(?:tring)?17') = ENV:D_string17,
('string17a', 'string17b') string20 : list of string
("s(?:tring)?20") = \ ENV:D_string20, (ENV:D_string20a, 'string20b')
string21, str21 : string ("^\\\d{2,3}\\\w\\\d{2,8}\$") = "333x29445"
name21, nm21 : name ('^\d{2,3}\w\d{2,8}') = $required file05, fl05 :
file = "~" file06 : file = "$HOME/bin" file07, fl07 : file =
'~other/bin' application08 : application = ENV:D_application08, `date`
key13 : list of key ENV:D_keys13, keyend = ENV:D_key13, \
("printer", ENV:D_key13b, ENV:D_keys13c) set01, st01 : set of :
integer (5 <= # <= 9) : real (5.0 <= # <= 9.0) : string ('pat01')
: key ak, bk, ck, dk, keyend end set set02, st02 : list of set
: integer (5 <= # <= 9) = (5, 7) : real (5.0 <= # <= 9.0) = (8.3,
5.0001) : string ('blah') = ("blah", "bbbbblahhhhh") : key ak, bk,
ck, dk, keyend = ("ak", "dk") end set PDTEND end-of-PDT
@MM = split /\n/, <<'end-of-MM'; expar_test.pl
This script simply tests the ExPar option parsing package.
Examples:
expar_test.pl
expar_test.pl -usage_help
expar_test.pl -help
expar_test.pl -full_help
expar_test.pl -partial_help
.switch01
A switch type parameter is either off or on, returning a 0 or 1
in the B<%OPT>: $OPT{'switch01'}.
.integer13
An integer type with a specified range and a default value. Integers
are checked against the pattern '[-+]?\d+', and, in this case, would
check to make sure that any command line value is greater than 5 and
less than or equal to 9.
.real70
An option of type real, checked against the following pattern:
'[+-]?(?:\d+(?:\.\d*)?|\.\d+)(?:[eE][+-]?\d+)?'. The default
values are 45 and 54. There are two default values because this
is a 'list of' type, which means that there may be multiple -real70
options in the command line. The value in B<%OPT> is an array
reference: $OPT{'real70'} = [45, 54].
Or, $OPT{'real70'}->[0] = 45, and
$OPT{'real70'}->[1] = 54.
.boolean07
A boolean type, also a list, can have be given one of the following
values: TRUE, FALSE, ON, OFF, 1, 0, YES, NO (case insensitive).
Returns either a 1 or 0.
.string17
A string type, also a list, with a pattern with which to check any
value specified in the command line. Any default values are also
checked against the specified pattern. In this case, D_string17 is
the default list, unless it does not exist, then the ending list
is assigned as the default. A string type is simply a string of
characters surrounded by quotes, either single or double quotes.
.string20
Another list of string type, showing an ENV variable, D_string20a, in
the default assignments. Also, a \ character, backslash, can be placed
at the end of a line in the B<@PDT> so that multiple lines may be used.
.string21
Still another string with a pattern surrounded by double-quotes. Notice
the use of multiple backslashes. Always be careful when pattern matching
on strings defined with single or double quotes.
.name21
The type name is treated identically to the type string. It is included
for backward compatibility with Getop::EvaP.
.file05
The type file is also the same as string type; however, $HOME and "~" are
expanded to $ENV{'HOME'}. Here the single '~' character is expanded.
Patterns are also allowed in file declaraions.
.file06
Here, $HOME is expanded to $ENV{'HOME'}.
.file07
In this case, the '~' is followed by a non-slash character. In UNIX, this
generally refers to the home directory of another user, and the '~' is
I expanded.
.application08
Treated as strings, but if surrounded by backtick characters, '`', it is
assumed to be an application and the returned value of this application
is stored. In this case, if the ENV variable D_application08 is not
defined, the default value of $OPT{'application08'} is set to what is
returned from the 'date' command: 'Mon Nov 9 15:23:47 CST 1998'.
.key13
The type key is an enumerated type allowing the programmer to explicitly
defined the possible values. Although the key type is functionally
equivalent to a string with a speicified pattern, it is left in for
backward compatibility. In this case, it is a list of keys whose
key values are defined by the ENV variable D_keys13.
.set01
A new 'supertype'. This allows for having multiple parameters for
a single option. From B<%OPT>, a set is an array of arrays, where each
sub-array holds the value(s) of a sub-type.
Ex: script.pl -set01 6 6.5 'pppat011' ck
$OPT{'set01'} = [ [ 6 ], [ 6.5 ], [ 'pppat011' ], [ 'ck' ] ];
.set02
A list of set. Assuming to -set02 options specified on the command line:
$OPT{'set01'} = [ [ 5, 7 ], [8.3, 5.0001], ["blah", "bbbbblahhhhh"], ["ak", "dk"] ];
end-of-MM
ExPar \@PDT, \@MM, \%OPT; # evaluate parameters
HELP
====
There are several levels of help created from the *@PDT* and *@MM*. It
is possible that the programmer may want to use one or more of these key
options in his *@PDT*. If this is the case, the built in functions can be
accessed by using two '-' characters instead of one. Built in help
functions include:
-help (-h) -full_help (-fh) -usage_help (-uh) -partial_help (-ph)
Currently, with the 0.01 alpha version, there is not much variety in
the help options. This author wanted to have a rudimentary help
available, while getting the package to end users for evaluation. Using
any one of these built in help options outputs the *@PDT* and *@MM* in a
text format.
Help
----
In development...
Full Help
---------
In development...
Usage Help
----------
In development...
Partial Help
------------
PLANNED FEATURES
================
Here are a few ideas for future enhancements. Currently, there is no
support for platforms other than UNIX and no support for languages other
than Perl. (What else could there be...:)
Partial Help Request
--------------------
A user may only want help with a specific option or subset of options.
Using *-partial_help*, the user can view the help for only those options
he/she wishes. This would be a subset of the *-full_help*.
Required, A Better Specification
--------------------------------
Whereas currently, to define an option to be required by the user, '=
$required' is placed at the end of a line in the PDT. However, this
method is limited. A method of implementing a more explicit and elaborate
definition of *$required* will be defined. This is the current thought:
In the PDT, a *$required* line may be placed in this manner:
$required : ((opta and optb) or (opta and not optb and optc) or \
(optc and optd and not optz))
This line is simply a Perl condition statement containing the names (or
aliases) of options defined in the PDT. Multiple *$required* lines may be
ANDed together.
Command Parameter Completion
----------------------------
Some shells in UNIX allow for command completion where the first few
letters of a command is typed in and a completion-key, ESC or TAB, is
pressed and the shell determines if enough letters have been typed to
distinguish from any other command. Some shells allow a refinement of
this by completing command parameters. In *tcsh*, this is done with the
complete command. For programs with a complex option set, the complete
command can become near unmanagable. This author proposes that by using
the *@PDT*, a complete command may be defined and returned to the user.
Perhaps by calling the perl script with a -complete (-complete) option
only, a complete definition would be printed to STDOUT.
POSSIBLE FEATURES
=================
Multiple Aliases
----------------
Although this would be fairly easy to do, it may not be necessary.
User feedback is welcome. Entries in *@PDT* would resemble this:
integer01, int01, i01, i1 : integer
User Requests
-------------
I will entertain any [sane] ideas that users may have...:)
NOTES
=====
Currently, the help system is minimal, but I wanted to get this
released to see who might use it.
This is currently *alpha* software. There are no doubt bugs and
shortcomings. Please email me at *hlhamilt@aud.alcatel.com* with
questions, comments, feature requests and bug reports.
VERSION HISTORY
===============
0.01
----
First *alpha* release. Help funcions are minimal. Might be buggy...:)
AUTHOR
======
Harlin L. Hamilton Jr.
Contact Info
------------
*mailto:hlhamilt@aud.alcatel.com*
Copyright
---------
Copyright (C) 1998 Harlin L. Hamilton Jr.. All rights reserved. This
package is free software; you can redistribute it and/or modify it under
the same terms as Perl itself.
File: pm.info, Node: Getopt/Long, Next: Getopt/Mixed, Prev: Getopt/ExPar, Up: Module List
Extended processing of command line options
*******************************************
NAME
====
Getopt::Long - Extended processing of command line options
SYNOPSIS
========
use Getopt::Long;
$result = GetOptions (...option-descriptions...);
DESCRIPTION
===========
The Getopt::Long module implements an extended getopt function called
GetOptions(). This function adheres to the POSIX syntax for command line
options, with GNU extensions. In general, this means that options have
long names instead of single letters, and are introduced with a double
dash "-". Support for bundling of command line options, as was the case
with the more traditional single-letter approach, is provided but not
enabled by default.
Command Line Options, an Introduction
=====================================
Command line operated programs traditionally take their arguments from
the command line, for example filenames or other information that the
program needs to know. Besides arguments, these programs often take
command line options as well. Options are not necessary for the program to
work, hence the name 'option', but are used to modify its default
behaviour. For example, a program could do its job quietly, but with a
suitable option it could provide verbose information about what it did.
Command line options come in several flavours. Historically, they are
preceded by a single dash -, and consist of a single letter.
-l -a -c
Usually, these single-character options can be bundled:
-lac
Options can have values, the value is placed after the option
character. Sometimes with whitespace in between, sometimes not:
-s 24 -s24
Due to the very cryptic nature of these options, another style was
developed that used long names. So instead of a cryptic -l one could use
the more descriptive `--long'. To distinguish between a bundle of
single-character options and a long one, two dashes are used to precede
the option name. Early implementations of long options used a plus +
instead. Also, option values could be specified either like
--size=24
or
--size 24
The + form is now obsolete and strongly deprecated.
Getting Started with Getopt::Long
=================================
Getopt::Long is the Perl5 successor of `newgetopt.pl'. This was the
first Perl module that provided support for handling the new style of
command line options, hence the name Getopt::Long. This module also
supports single-character options and bundling. In this case, the options
are restricted to alphabetic characters only, and the characters ? and -.
To use Getopt::Long from a Perl program, you must include the following
line in your Perl program:
use Getopt::Long;
This will load the core of the Getopt::Long module and prepare your
program for using it. Most of the actual Getopt::Long code is not loaded
until you really call one of its functions.
In the default configuration, options names may be abbreviated to
uniqueness, case does not matter, and a single dash is sufficient, even
for long option names. Also, options may be placed between non-option
arguments. See `Configuring Getopt::Long' in this node for more details on
how to configure Getopt::Long.
Simple options
--------------
The most simple options are the ones that take no values. Their mere
presence on the command line enables the option. Popular examples are:
--all --verbose --quiet --debug
Handling simple options is straightforward:
my $verbose = ''; # option variable with default value (false)
my $all = ''; # option variable with default value (false)
GetOptions ('verbose' => \$verbose, 'all' => \$all);
The call to GetOptions() parses the command line arguments that are
present in `@ARGV' and sets the option variable to the value 1 if the
option did occur on the command line. Otherwise, the option variable is
not touched. Setting the option value to true is often called *enabling*
the option.
The option name as specified to the GetOptions() function is called the
option *specification*. Later we'll see that this specification can
contain more than just the option name. The reference to the variable is
called the option *destination*.
GetOptions() will return a true value if the command line could be
processed successfully. Otherwise, it will write error messages to STDERR,
and return a false result.
A little bit less simple options
--------------------------------
Getopt::Long supports two useful variants of simple options:
*negatable* options and incremental options.
A negatable option is specified with a exclamation mark ! after the
option name:
my $verbose = ''; # option variable with default value (false)
GetOptions ('verbose!' => \$verbose);
Now, using `--verbose' on the command line will enable `$verbose', as
expected. But it is also allowed to use `--noverbose', which will disable
`$verbose' by setting its value to 0. Using a suitable default value, the
program can find out whether `$verbose' is false by default, or disabled
by using `--noverbose'.
An incremental option is specified with a plus + after the option name:
my $verbose = ''; # option variable with default value (false)
GetOptions ('verbose+' => \$verbose);
Using `--verbose' on the command line will increment the value of
`$verbose'. This way the program can keep track of how many times the
option occurred on the command line. For example, each occurrence of
`--verbose' could increase the verbosity level of the program.
Mixing command line option with other arguments
-----------------------------------------------
Usually programs take command line options as well as other arguments,
for example, file names. It is good practice to always specify the options
first, and the other arguments last. Getopt::Long will, however, allow the
options and arguments to be mixed and 'filter out' all the options before
passing the rest of the arguments to the program. To stop Getopt::Long
from processing further arguments, insert a double dash - on the command
line:
--size 24 -- --all
In this example, `--all' will not be treated as an option, but passed
to the program unharmed, in `@ARGV'.
Options with values
-------------------
For options that take values it must be specified whether the option
value is required or not, and what kind of value the option expects.
Three kinds of values are supported: integer numbers, floating point
numbers, and strings.
If the option value is required, Getopt::Long will take the command
line argument that follows the option and assign this to the option
variable. If, however, the option value is specified as optional, this
will only be done if that value does not look like a valid command line
option itself.
my $tag = ''; # option variable with default value
GetOptions ('tag=s' => \$tag);
In the option specification, the option name is followed by an equals
sign = and the letter s. The equals sign indicates that this option
requires a value. The letter s indicates that this value is an arbitrary
string. Other possible value types are i for integer values, and f for
floating point values. Using a colon : instead of the equals sign
indicates that the option value is optional. In this case, if no suitable
value is supplied, string valued options get an empty string " assigned,
while numeric options are set to 0.
Options with multiple values
----------------------------
Options sometimes take several values. For example, a program could use
multiple directories to search for library files:
--library lib/stdlib --library lib/extlib
To accomplish this behaviour, simply specify an array reference as the
destination for the option:
my @libfiles = ();
GetOptions ("library=s" => \@libfiles);
Used with the example above, `@libfiles' would contain two strings upon
completion: `"lib/srdlib"' and `"lib/extlib"', in that order. It is also
possible to specify that only integer or floating point numbers are
acceptible values.
Often it is useful to allow comma-separated lists of values as well as
multiple occurrences of the options. This is easy using Perl's split() and
join() operators:
my @libfiles = ();
GetOptions ("library=s" => \@libfiles);
@libfiles = split(/,/,join(',',@libfiles));
Of course, it is important to choose the right separator string for
each purpose.
Options with hash values
------------------------
If the option destination is a reference to a hash, the option will
take, as value, strings of the form key=value. The value will be stored
with the specified key in the hash.
my %defines = ();
GetOptions ("define=s" => \%defines);
When used with command line options:
--define os=linux --define vendor=redhat
the hash `%defines' will contain two keys, `"os"' with value `"linux'
and `"vendor"' with value `"redhat"'. It is also possible to specify that
only integer or floating point numbers are acceptible values. The keys are
always taken to be strings.
User-defined subroutines to handle options
------------------------------------------
Ultimate control over what should be done when (actually: each time) an
option is encountered on the command line can be achieved by designating a
reference to a subroutine (or an anonymous subroutine) as the option
destination. When GetOptions() encounters the option, it will call the
subroutine with two arguments: the name of the option, and the value to be
assigned. It is up to the subroutine to store the value, or do whatever it
thinks is appropriate.
A trivial application of this mechanism is to implement options that
are related to each other. For example:
my $verbose = ''; # option variable with default value (false)
GetOptions ('verbose' => \$verbose,
'quiet' => sub { $verbose = 0 });
Here `--verbose' and `--quiet' control the same variable `$verbose',
but with opposite values.
If the subroutine needs to signal an error, it should call die() with
the desired error message as its argument. GetOptions() will catch the
die(), issue the error message, and record that an error result must be
returned upon completion.
If the text of the error message starts with an exclamantion mark ! it
is interpreted specially by GetOptions(). There is currently one special
command implemented: `die("!FINISH")' will cause GetOptions() to stop
processing options, as if it encountered a double dash -.
Options with multiple names
---------------------------
Often it is user friendly to supply alternate mnemonic names for
options. For example `--height' could be an alternate name for `--length'.
Alternate names can be included in the option specification, separated by
vertical bar | characters. To implement the above example:
GetOptions ('length|height=f' => \$length);
The first name is called the *primary* name, the other names are called
aliases.
Multiple alternate names are possible.
Case and abbreviations
----------------------
Without additional configuration, GetOptions() will ignore the case of
option names, and allow the options to be abbreviated to uniqueness.
GetOptions ('length|height=f' => \$length, "head" => \$head);
This call will allow `--l' and `--L' for the length option, but
requires a least `--hea' and `--hei' for the head and height options.
Summary of Option Specifications
--------------------------------
Each option specifier consists of two parts: the name specification and
the argument specification.
The name specification contains the name of the option, optionally
followed by a list of alternative names separated by vertical bar
characters.
length option name is "length"
length|size|l name is "length", aliases are "size" and "l"
The argument specification is optional. If omitted, the option is
considered boolean, a value of 1 will be assigned when the option is used
on the command line.
The argument specification can be
!
The option does not take an argument and may be negated, i.e. prefixed
by "no". E.g. `"foo!"' will allow `--foo' (a value of 1 will be
assigned) and `--nofoo' (a value of 0 will be assigned). If the
option has aliases, this applies to the aliases as well.
Using negation on a single letter option when bundling is in effect is
pointless and will result in a warning.
+
The option does not take an argument and will be incremented by 1
every time it appears on the command line. E.g. `"more+"', when used
with `--more --more --more', will increment the value three times,
resulting in a value of 3 (provided it was 0 or undefined at first).
The + specifier is ignored if the option destination is not a scalar.
= type [ *desttype* ]
The option requires an argument of the given type. Supported types
are:
s
String. An arbitrary sequence of characters. It is valid for the
argument to start with - or -.
i
Integer. An optional leading plus or minus sign, followed by a
sequence of digits.
f
Real number. For example `3.14', `-6.23E24' and so on.
The *desttype* can be `@' or % to specify that the option is list or
a hash valued. This is only needed when the destination for the
option value is not otherwise specified. It should be omitted when
not needed.
: type [ *desttype* ]
Like =, but designates the argument as optional. If omitted, an
empty string will be assigned to string values options, and the value
zero to numeric options.
Note that if a string argument starts with - or -, it will be
considered an option on itself.
Advanced Possibilities
======================
Object oriented interface
-------------------------
Getopt::Long can be used in an object oriented way as well:
use Getopt::Long;
$p = new Getopt::Long::Parser;
$p->configure(...configuration options...);
if ($p->getoptions(...options descriptions...)) ...
Configuration options can be passed to the constructor:
$p = new Getopt::Long::Parser
config => [...configuration options...];
For thread safety, each method call will acquire an exclusive lock to
the Getopt::Long module. So don't call these methods from a callback
routine!
Documentation and help texts
----------------------------
Getopt::Long encourages the use of Pod::Usage to produce help messages.
For example:
use Getopt::Long;
use Pod::Usage;
my $man = 0;
my $help = 0;
GetOptions('help|?' => \$help, man => \$man) or pod2usage(2);
pod2usage(1) if $help;
pod2usage(-exitstatus => 0, -verbose => 2) if $man;
__END__
=head1 NAME
sample - Using GetOpt::Long and Pod::Usage
=head1 SYNOPSIS
sample [options] [file ...]
Options:
-help brief help message
-man full documentation
=head1 OPTIONS
=over 8
=item B<-help>
Print a brief help message and exits.
=item B<-man>
Prints the manual page and exits.
=back
=head1 DESCRIPTION
B will read the given input file(s) and do someting
useful with the contents thereof.
=cut
See *Note Pod/Usage: Pod/Usage, for details.
Storing options in a hash
-------------------------
Sometimes, for example when there are a lot of options, having a
separate variable for each of them can be cumbersome. GetOptions()
supports, as an alternative mechanism, storing options in a hash.
To obtain this, a reference to a hash must be passed *as the first
argument* to GetOptions(). For each option that is specified on the
command line, the option value will be stored in the hash with the option
name as key. Options that are not actually used on the command line will
not be put in the hash, on other words, `exists($h{option})' (or
defined()) can be used to test if an option was used. The drawback is that
warnings will be issued if the program runs under `use strict' and uses
`$h{option}' without testing with exists() or defined() first.
my %h = ();
GetOptions (\%h, 'length=i'); # will store in $h{length}
For options that take list or hash values, it is necessary to indicate
this by appending an `@' or % sign after the type:
GetOptions (\%h, 'colours=s@'); # will push to @{$h{colours}}
To make things more complicated, the hash may contain references to the
actual destinations, for example:
my $len = 0;
my %h = ('length' => \$len);
GetOptions (\%h, 'length=i'); # will store in $len
This example is fully equivalent with:
my $len = 0;
GetOptions ('length=i' => \$len); # will store in $len
Any mixture is possible. For example, the most frequently used options
could be stored in variables while all other options get stored in the
hash:
my $verbose = 0; # frequently referred
my $debug = 0; # frequently referred
my %h = ('verbose' => \$verbose, 'debug' => \$debug);
GetOptions (\%h, 'verbose', 'debug', 'filter', 'size=i');
if ( $verbose ) { ... }
if ( exists $h{filter} ) { ... option 'filter' was specified ... }
Bundling
--------
With bundling it is possible to set several single-character options at
once. For example if a, v and x are all valid options,
-vax
would set all three.
Getopt::Long supports two levels of bundling. To enable bundling, a
call to Getopt::Long::Configure is required.
The first level of bundling can be enabled with:
Getopt::Long::Configure ("bundling");
Configured this way, single-character options can be bundled but long
options must always start with a double dash - to avoid abiguity. For
example, when `vax', a, v and x are all valid options,
-vax
would set a, v and x, but
--vax
would set `vax'.
The second level of bundling lifts this restriction. It can be enabled
with:
Getopt::Long::Configure ("bundling_override");
Now, `-vax' would set the option `vax'.
When any level of bundling is enabled, option values may be inserted in
the bundle. For example:
-h24w80
is equivalent to
-h 24 -w 80
When configured for bundling, single-character options are matched case
sensitive while long options are matched case insensitive. To have the
single-character options matched case insensitive as well, use:
Getopt::Long::Configure ("bundling", "ignorecase_always");
It goes without saying that bundling can be quite confusing.
The lonesome dash
-----------------
Normally, a lone dash - on the command line will not be considered an
option. Option processing will terminate (unless "permute" is configured)
and the dash will be left in `@ARGV'.
It is possible to get special treatment for a lone dash. This can be
achieved by adding an option specification with an empty name, for example:
GetOptions ('' => \$stdio);
A lone dash on the command line will now be a legal option, and using
it will set variable `$stdio'.
Argument call-back
------------------
A special option 'name' <> can be used to designate a subroutine to
handle non-option arguments. When GetOptions() encounters an argument that
does not look like an option, it will immediately call this subroutine and
passes it the argument as a parameter.
For example:
my $width = 80;
sub process { ... }
GetOptions ('width=i' => \$width, '<>' => \&process);
When applied to the following command line:
arg1 --width=72 arg2 --width=60 arg3
This will call `process("arg1")' while $width is 80, `process("arg2")'
while $width is 72, and `process("arg3")' while $width is 60.
This feature requires configuration option permute, see section
`Configuring Getopt::Long' in this node.
Configuring Getopt::Long
========================
Getopt::Long can be configured by calling subroutine
Getopt::Long::Configure(). This subroutine takes a list of quoted strings,
each specifying a configuration option to be enabled, e.g. ignore_case,
or disabled, e.g. `no_ignore_case'. Case does not matter. Multiple calls
to Configure() are possible.
Alternatively, as of version 2.24, the configuration options may be
passed together with the use statement:
use Getopt::Long qw(:config no_ignore_case bundling);
The following options are available:
default
This option causes all configuration options to be reset to their
default values.
posix_default
This option causes all configuration options to be reset to their
default values as if the environment variable POSIXLY_CORRECT had
been set.
auto_abbrev
Allow option names to be abbreviated to uniqueness. Default is
enabled unless environment variable POSIXLY_CORRECT has been set, in
which case auto_abbrev is disabled.
getopt_compat
Allow + to start options. Default is enabled unless environment
variable POSIXLY_CORRECT has been set, in which case getopt_compat is
disabled.
gnu_compat
gnu_compat controls whether `--opt=' is allowed, and what it should
do. Without gnu_compat, `--opt=' gives an error. With gnu_compat,
`--opt=' will give option opt and empty value. This is the way GNU
getopt_long() does it.
gnu_getopt
This is a short way of setting gnu_compat bundling permute
`no_getopt_compat'. With gnu_getopt, command line handling should be
fully compatible with GNU getopt_long().
require_order
Whether command line arguments are allowed to be mixed with options.
Default is disabled unless environment variable POSIXLY_CORRECT has
been set, in which case require_order is enabled.
See also permute, which is the opposite of require_order.
permute
Whether command line arguments are allowed to be mixed with options.
Default is enabled unless environment variable POSIXLY_CORRECT has
been set, in which case permute is disabled. Note that permute is
the opposite of require_order.
If permute is enabled, this means that
--foo arg1 --bar arg2 arg3
is equivalent to
--foo --bar arg1 arg2 arg3
If an argument call-back routine is specified, `@ARGV' will always be
empty upon succesful return of GetOptions() since all options have
been processed. The only exception is when - is used:
--foo arg1 --bar arg2 -- arg3
will call the call-back routine for arg1 and arg2, and terminate
GetOptions() leaving `"arg2"' in `@ARGV'.
If require_order is enabled, options processing terminates when the
first non-option is encountered.
--foo arg1 --bar arg2 arg3
is equivalent to
--foo -- arg1 --bar arg2 arg3
If pass_through is also enabled, options processing will terminate at
the first unrecognized option, or non-option, whichever comes first.
bundling (default: disabled)
Enabling this option will allow single-character options to be
bundled. To distinguish bundles from long option names, long options
must be introduced with - and single-character options (and bundles)
with -.
Note: disabling bundling also disables bundling_override.
bundling_override (default: disabled)
If bundling_override is enabled, bundling is enabled as with bundling
but now long option names override option bundles.
Note: disabling bundling_override also disables bundling.
Note: Using option bundling can easily lead to unexpected results,
especially when mixing long options and bundles. Caveat emptor.
ignore_case (default: enabled)
If enabled, case is ignored when matching long option names. Single
character options will be treated case-sensitive.
Note: disabling ignore_case also disables ignore_case_always.
ignore_case_always (default: disabled)
When bundling is in effect, case is ignored on single-character
options also.
Note: disabling ignore_case_always also disables ignore_case.
pass_through (default: disabled)
Options that are unknown, ambiguous or supplied with an invalid option
value are passed through in `@ARGV' instead of being flagged as
errors. This makes it possible to write wrapper scripts that process
only part of the user supplied command line arguments, and pass the
remaining options to some other program.
If require_order is enabled, options processing will terminate at the
first unrecognized option, or non-option, whichever comes first.
However, if permute is enabled instead, results can become confusing.
prefix
The string that starts options. If a constant string is not
sufficient, see prefix_pattern.
prefix_pattern
A Perl pattern that identifies the strings that introduce options.
Default is `(--|-|\+)' unless environment variable POSIXLY_CORRECT
has been set, in which case it is `(--|-)'.
debug (default: disabled)
Enable debugging output.
Return values and Errors
========================
Configuration errors and errors in the option definitions are signalled
using die() and will terminate the calling program unless the call to
Getopt::Long::GetOptions() was embedded in `eval { ... }', or die() was
trapped using `$SIG{__DIE__}'.
GetOptions returns true to indicate success. It returns false when the
function detected one or more errors during option parsing. These errors
are signalled using warn() and can be trapped with `$SIG{__WARN__}'.
Errors that can't happen are signalled using Carp::croak().
Legacy
======
The earliest development of `newgetopt.pl' started in 1990, with Perl
version 4. As a result, its development, and the development of
Getopt::Long, has gone through several stages. Since backward
compatibility has always been extremely important, the current version of
Getopt::Long still supports a lot of constructs that nowadays are no
longer necessary or otherwise unwanted. This section describes briefly
some of these 'features'.
Default destinations
--------------------
When no destination is specified for an option, GetOptions will store
the resultant value in a global variable named `opt_'XXX, where XXX is the
primary name of this option. When a progam executes under `use strict'
(recommended), these variables must be pre-declared with our() or `use
vars'.
our $opt_length = 0;
GetOptions ('length=i'); # will store in $opt_length
To yield a usable Perl variable, characters that are not part of the
syntax for variables are translated to underscores. For example,
`--fpp-struct-return' will set the variable `$opt_fpp_struct_return'. Note
that this variable resides in the namespace of the calling program, not
necessarily main. For example:
GetOptions ("size=i", "sizes=i@");
with command line "-size 10 -sizes 24 -sizes 48" will perform the
equivalent of the assignments
$opt_size = 10;
@opt_sizes = (24, 48);
Alternative option starters
---------------------------
A string of alternative option starter characters may be passed as the
first argument (or the first argument after a leading hash reference
argument).
my $len = 0;
GetOptions ('/', 'length=i' => $len);
Now the command line may look like:
/length 24 -- arg
Note that to terminate options processing still requires a double dash
-.
GetOptions() will not interpret a leading `< "<'" >> as option starters
if the next argument is a reference. To force `< "<" '> and `< "'" >> as
option starters, use `< "'<" >>. Confusing? Well, *using a starter
argument is strongly deprecated* anyway.
Configuration variables
-----------------------
Previous versions of Getopt::Long used variables for the purpose of
configuring. Although manipulating these variables still work, it is
strongly encouraged to use the Configure routine that was introduced in
version 2.17. Besides, it is much easier.
Trouble Shooting
================
Warning: Ignoring '!' modifier for short option
-----------------------------------------------
This warning is issued when the '!' modifier is applied to a short
(one-character) option and bundling is in effect. E.g.,
Getopt::Long::Configure("bundling");
GetOptions("foo|f!" => \$foo);
Note that older Getopt::Long versions did not issue a warning, because
the '!' modifier was applied to the first name only. This bug was fixed in
2.22.
Solution: separate the long and short names and apply the '!' to the
long names only, e.g.,
GetOptions("foo!" => \$foo, "f" => \$foo);
GetOptions does not return a false result when an option is not supplied
------------------------------------------------------------------------
That's why they're called 'options'.
AUTHOR
======
Johan Vromans
COPYRIGHT AND DISCLAIMER
========================
This program is Copyright 2000,1990 by Johan Vromans. This program is
free software; you can redistribute it and/or modify it under the terms of
the Perl Artistic License or the GNU General Public License as published
by the Free Software Foundation; either version 2 of the License, or (at
your option) any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
If you do not have a copy of the GNU General Public License write to
the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.