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

I wish to create a wrapper script that checks certain arguments for type yet passes along all unrecognized arguments to ARGV. I thought I figured out the correct syntax for Getopt::Long:Configure but the arguments are NOT seemed to be checked for proper type. I've type the following and I'm not seeing my code exit: 

testscript -lib 1.0 -cell -a -f

[download]

-------------- testscript --------------------------- 

#!/usr/bin/perl

use vars qw($opt_lib $opt_cell);
use IO::File;
use English;
use strict;
use Getopt::Long; 
Getopt::Long::Configure('no_auto_abbrev','pass_through');
GetOptions('lib=s','cell=s') or exit 1;

[download]

Thanks for any help you can provide.

Edit: g0n - code tags and formatting

Replies are listed 'Best First'.
Re: Issues w/ getOptions parsing options with pass_through enabled
by ikegami (Patriarch) on May 23, 2006 at 17:26 UTC

    With Getopt::Long 2.25, I get the results I expect.

    • The argument after -lib (the string 1.0) is assigned to $opt_lib (i.e. $opt_lib = "1.0";).

    • The argument after -cell (the string -a) is assigned to $opt_cell (i.e. $opt_cell = "-a";).

    • Unrecognized parameter -f remains in @ARGV (i.e. @ARGV = ("-f");).

    • exit didn't get executed. There was no error except the unrecognized parameter -f, but pass_through allows that.

    What results are you expecting?

[reply]
[d/l]
[select]

      Intuitively (i.e. without looking at any documentation), I'd expect the -a to be seen as an unrecognized parameter, and thus the code to error out because -cell didn't get a parameter.

[reply]
[d/l]
[select]

        How do you expect to know what any of the options means — or that they even exist — without reading the program's docs?

        Scenario 1

        You, as a reader of the command line, are making the *assumption* that -a is an option. The crafter of the command line should have avoided that confusion by using -cell=-a, but that doesn't excuse the negligence of the reader.

        Scenario 2

        You, as the crafter of the command line, don't know that -cell requires a parameter. The problem could be:

        • You read the program's docs, but they were incomplete.
        • You read the program's docs, but they were unclear.
        • You didn't read the program's docs, and you made the *assumption* that -cell didn't require a parameter.

        That's why it's important for the programmer to validate the input from the user. In all three cases, having something like the following would have helped: 

        usage("Bad value $opt_cell for option -cell")
   unless is_valid_cell($opt_cell);

        [download]
[reply]
[d/l]
[select]
Re: Issues w/ getOptions parsing options with pass_through enabled
by Brawny1 (Initiate) on May 24, 2006 at 13:30 UTC
    Okay, I used a bad example to show my problem. I can see that the parser is just treating -a as string for -cell. Is there a way for GetOpts to not treat -a as string for -cell and treat it as an argument because of the dash? Even so if you change lib=s to lib=f and then use the following command it still does not complain (and error out since lib should be a float): testscript -lib string
[reply]

      Even so if you change lib=s to lib=f and then use the following command it still does not complain (and error out since lib should be a float)

      It's not an error because of pass_through. It causes anything wrong to left in @ARGV for further processing. For example, 

      use Getopt::Long (); 

our $opt_float;

Getopt::Long::Configure('no_auto_abbrev','pass_through');
Getopt::Long::GetOptions('float=f')
   or die("Bad args\n");

print("\$opt_float = ", defined($opt_float) ? $opt_float : "[undef]", 
+"\n");
print("\@ARGV      = ", join(' ', @ARGV), "\n");

      [download]

      returns 

      >perl 551380.pl -float 1.3
$opt_float = 1.3
@ARGV      =

>perl 551380.pl -float abc
$opt_float = [undef]
@ARGV      = -float abc

      [download]
[reply]
[d/l]
[select]
        I'm not arguing with your explanation of how things are working w/ pass_through. I'm asking if was anything in the settings to make it work differently. The problem in the second example you showed is that if I have in the code constructs to set $opt_float to a value to if it is undefined then I have unintended program execution despite the fact that there is a user command line type error. It requires me to parse ARGV to check against such a scenario. Again, sorry for accidently starting two separate sub-threads on this topic. Thanks for you help.
[reply]

Back to Seekers of Perl Wisdom