[Chicago-talk] alternatives to Getopt::Long

[Wiggins d Anconia]

> 
> On Fri, 7 May 2004, Steven Lembark wrote:
> > -- Mike Fragassi <frag at ripco.com>
> > > Getopt::Long doesn't seem to have the ability to take command-line
> > > arguments like
> > >
> > >    --foo a b c --bar 1 2 3
> >
> > There is now way for it to know that "a b c" is an argument.
> 
> But why not?  You can already do
> 
>    GetOptions('foo=s' => \@foo);
> 
> It should at least be feasible to go
> 
>    GetOptions('foo=s+' => \@foo);  # or 'foo=sl', or 'foo=S', or whatever

If I understand correctly it is so that there can be a distinction
between what is an argument and what is an input file.  Normally the
shell (at least in the GNU world) would interpret "a b c" as input files
rather than command switches.  The problem becomes how does GetOpt
understand the distinction between what is a listed argument and what is
an input file. Enter the commas, verbose switching, etc.  The + is an
interesting notion but adds one additional step and complexity just to
prevent the need for user to "just do it the way everyone else does". 
To me this adds testing steps, documentation, (dumb) user support, etc.


> 
> which could tell it to keep shifting @ARGV into @foo until you hit the
> next --switch.  Or a configuration parameter (like 'auto_abbrev' or
> 'permute') to do this for all array parameters by default.  I haven't
> tried hacking Getopt::Long (yet), but I was surprised this sort of thing
> isn't in place.
>

Problem becomes what if there isn't a next switch, then your user has to
remember to throw a '--' in there or something similar, if they can't
remember to add commas between options how are they going to remember to
add a '--' between command arguments and input files.  
 
After seeing the problems that arise in the GnuPG world when a user
doesn't understand the difference between an option and an argument I
would hate to add this kind of thing to any application.

Just some thoughts...

http://danconia.org