[Chicago-talk] alternatives to Getopt::Long

Steven Lembark lembark at wrkhors.com
Sat May 8 20:56:58 CDT 2004


> 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.

No, the shell doesn't interpret anything that isn't
on one end of a redirect (e.g., '> foobar'). These
do not show up as arguments to the running process,
however. The issue here has noting to do with perl,
it's how the shell expands the line being passed
into the second argument (char **argv) of the proc.


> 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.

Yup. Which is why the simplest fix is to either use multiple
--foo=bar entries to build the array or --foo='bar bletch'
to protect the whitespace from being gobbled up by the shell
before perl has a chance to see it.


--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 888 359 3508



More information about the Chicago-talk mailing list