Front page | perl.perl5.porters |
Postings from April 2003
Re: [PATCH 5.8.1 @19053] Getopt::Std
From: Ilya Zakharevich
April 3, 2003 12:54
Re: [PATCH 5.8.1 @19053] Getopt::Std
Message ID: 20030403205439.GA6109@math.berkeley.edu
On Thu, Apr 03, 2003 at 11:44:01AM +0200, Johan Vromans wrote:
> > +If C<-> is not a recognized option letter, getopts() supports arguments
> > +C<--help> and C<--version>.
> For Getopt::Long that would mean: add a '--help' and '--version'
> option if the program did not specify one itself.
I think so too..
> > If C<HELP_MESSAGE()> or C<VERSION_MESSAGE()> are
> > +defined in the package C<main>, they are called (with the switches string
> > +and C<GetOpt::Std> version as arguments); if not, an attempt is made to
> > +generate intelligent messages; for best results, define $main::VERSION.
> I can imagine why the switches string is passed to HELP_MESSAGE, but
> why is it passed to VERSION_MESSAGE?
For consistency only.
> Also, I think it is not necessary to pass the version to the callback
> routine, since it is available as $Getopt::Std::VERSION anyway.
IMO, it is cleaner to use arguments than the global data.
> Instead, it would be better to pass the name of the package that does
> the options parsing (e.g., 'Getopt::Std'). In particular w.r.t. your
> proposal for --getopt-ui (not --getopt-gui!).
Good ideas too!
> > +In presence of these arguments getopts() calls
> > +C<exit($GetOpt::Std::EXIT_ON_HELP_VERSION)> if
> > +$GetOpt::Std::EXIT_ON_HELP_VERSION is defined.
> I would suggest separate values for $EXIT_ON_HELP and
> $EXIT_ON_VERSION. Rationale: If we later invent a third callback FOO,
> we prevent the strange case of --version and --help returning
> EXIT_ON_HELP_VERSION, while --foo returns EXIT_ON_FOO. Or --foo has to
> return EXIT_ON_HELP_VERSION as well, which is also confusing.
The only purpose of $EXIT_ON_HELP_VERSION is the backward
compatibility, so one cannot make an arbitrary script exit early by
providing --help option. This proposal looks like hair splitting; on
the other hand, it is trivial to implement: just check the variables
when setting $exit, not at the end of parsing...
> Also, I would prefer
> use constant EXIT_ON_HELP_VERSION => 681;
> instead of
> our $EXIT_ON_HELP_VERSION = 681;
Do not think so. The fact that `use constant' is not lexical is just
a feature of implementation.
> > +$0 version $v calling Getopt::Std::getopts (version $VERSION),
> $0 may be set to something else and no longer reflect the program
> name. Intgentional? Acceptable?
IIUC, $0 is as good as it gets.
> > ["input|i=s", argname => 'PATCHFILE',
> > help => 'Read patch from PATCHFILE instead of stdin.'],
> I think it is easy and unabiguous to deduce the argname from the help
> text, E.g.:
> "input|i=s?Read patch from <PATCHFILE> instead of stdin.",
> This would allow implementation within the current Getopt::Long API.
Maybe. Only make the delimiter less frequent; e.g., "from <<<PATCHFILE>>>".
> > c) There should be a way to request/suppress sorting of options on --help.
> I would never sort the options.
My usages of getopts() have switches in random order. So I do not
care if they are sorted. And if order does not matter, it is better
to sort (especially if the list is long). So I think sorting may have
> > --getopt-gui=Foo,Bar
> > If Getopt::Long finds this option, it should try to delegate work
> > to Getopt::Foo, if not present to Getopt::Bar, if not present,
> Extremely powerful, but also extremely dangerous. For one,
> Getopt::Foo, Getopt::Bar and so on would have to support identical
But this is a users responsibility. If the user chooses
--getopt-ui=Tree, then we may assume they know something about
Hmm, versioning needs to be done. The script should be able to
communicate which minimal version of Getopt::Long API it needs
(probably, differently than in 'use' line, unless Getopt::Long can
catch this). Then Getopt::Long may interrogate Getopt::Tree whether
it supports the API.
Hope this helps,