[Chicago-talk] alternatives to Getopt::Long

Mike Fragassi frag at ripco.com
Mon May 10 09:24:21 CDT 2004

On Sun, 9 May 2004, Steven Lembark wrote:
> -- Mike Fragassi <frag at ripco.com>
> > The point is not to prevent @AGRV from being split on \s+, the point is
> > that the @ARGV processor could assign multiple values to the designated
> > array until it reaches the next switch.
> How would you handle:
>     foo --bar bletch blort blam;
> with "blam" being the first program argument, bletch and blort
> being arguments to the --bar switch?  Or deal gracefully with
> single-dash switches:

If you read my other emails, you'd note that in my case I do not have
program arguments unattached to switches, and I am not arguing for this
being the one way everyone should always do things.  (Nor am I saying this
is the one way I intend to always do things, nor am I saying this is
in general the better way.)

> Or deal gracefully with single-dash switches:
>     foo -bletch -b blort blam;

Easy: the same way that Getopt::Long does it.

> let alone combined ones.

The same way that Getopt::Long does it.

> If you can figure out a reliable way to handle this that doesn't
> involve more typing than multiple use of the switches feel free,
> but the existing system exists largely because noone has found
> any really better one.

Searching CPAN for 'Getopt' yields 39 modules.  There Is More Than One
Way To Do It.  And all I'm asking is if anyone knows if any of them does
what I'm describing.  (Presently, I'm looking at Getopt::Declare,
which apparently permits the following:

        -pages 1
        -pages 1 2 7 20
	--window <height> x <width>

It's written by some Australian guy you probably haven't heard of.)

-- Mike F.

More information about the Chicago-talk mailing list