getopts and ARGV

rugwuk has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

I am using getopts for argument processing, thus

print_usage if ( ! getopts(':hxarw:l:f:c:e:s:R:v:', \%opts) || exists($opts{h}));

in the hope that when configured incorrectly (from an arg perspective), it will print_usage.However when i run my program thus

lock -c test -l test -f locktest -x -r 5

getopts does not complain about the -r argument having value 5, nor does getopts complain when i do

lock -c test -l test -f locktest -x 5 -r

it simply obeys the : rules and throws that stuff away..:-)

Is there a recommended way to compare actual cmd line args vs what getopts expects?

In the end i wrote a short loop to total up arguments in %opts hash thus

foreach my $arg ( keys %opts ) {
        log_debug "Argument $arg has value $opts{$arg}";
        log_debug "Pre Running total is $getopts_args";
        if ( $opts{$arg} eq "1" ) {
            $getopts_args += 1;
        } else {
            $getopts_args+= 2;
        }
        log_debug "Post Running total is $getopts_args";
    }
[download]

which i compare aginst scalar @ARGV if they don't match i carp

Am i insane? Rgds Richard

Comment on getopts and ARGV Select or Download Code

Replies are listed 'Best First'.
(jcwren) Re: getopts and ARGV by jcwren (Prior) on May 27, 2002 at 21:47 UTC
Although seemingly undocumented, `getopts()` stops parsing as soon as it hits a non-switch formatted argument (an argument that doesn't have a leading dash) in the command line that doesn't have a preceeding switch that accepts a parameter. Assuming you have `getopts (":abcd:e:")`, the following cases apply: `perl test.pl -a -d 5` `getopts()` returns a non-zero value, the hash contains -a=1, -d=5, and `@ARGV` is 0 length. `perl test.pl -a -u -d 5` `getopts()` returns a zero value, the hash contains -a=1, -d=5, and `@ARGV` is 0 length.. A warning is also printed from inside `getopts()` `perl test.pl -a xxx -d 5` returns a zero value, the hash contains -a=1, and `@ARGV` contains 'xxx', '-d', '5' You can use the fact that `@ARGV` still contains values to print an error message. Or, you could get more sophisticated, and do something with the unparsed argument. Since the arguments are dropped from `@ARGV` as they are parsed, you could stay in a loop until `@ARGV` is 0, print "I don't recognize this argument: $@ARGV[0]\n", shift `@ARGV`, and call `getopts()` again. This will result in your hash containing all the valid arguments that were on the command line, and personalized messages for ones that are invalid. --Chris e-mail jcwren	[reply] [d/l] [select]

Replies are listed 'Best First'.

(jcwren) Re: getopts and ARGV
by jcwren (Prior) on May 27, 2002 at 21:47 UTC

Although seemingly undocumented, getopts() stops parsing as soon as it hits a non-switch formatted argument (an argument that doesn't have a leading dash) in the command line that doesn't have a preceeding switch that accepts a parameter.

Assuming you have getopts (":abcd:e:"), the following cases apply:

perl test.pl -a -d 5

getopts() returns a non-zero value, the hash contains -a=1, -d=5, and @ARGV is 0 length.

perl test.pl -a -u -d 5

getopts() returns a zero value, the hash contains -a=1, -d=5, and @ARGV is 0 length.. A warning is also printed from inside getopts()

perl test.pl -a xxx -d 5

returns a zero value, the hash contains -a=1, and @ARGV contains 'xxx', '-d', '5'

You can use the fact that @ARGV still contains values to print an error message. Or, you could get more sophisticated, and do something with the unparsed argument. Since the arguments are dropped from @ARGV as they are parsed, you could stay in a loop until @ARGV is 0, print "I don't recognize this argument: $@ARGV[0]\n", shift @ARGV, and call getopts() again. This will result in your hash containing all the valid arguments that were on the command line, and personalized messages for ones that are invalid.

--Chris

e-mail jcwren

[reply]
[d/l]
[select]