Re^3: Issues w/ getOptions parsing options with pass

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.

Comment on Re^3: Issues w/ getOptions parsing options with pass_through enabled

Replies are listed 'Best First'.
Re^4: Issues w/ getOptions parsing options with pass_through enabled by ikegami (Patriarch) on May 24, 2006 at 16:30 UTC
I'm asking if was anything in the settings to make it work differently. Yes. If you don't want `pass_through`'s behaviour, don't use `pass_through`. `use Getopt::Long (); our $opt_float; Getopt::Long::Configure('no_auto_abbrev'); 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] outputs `>perl 551404.pl -float 1.3 $opt_float = 1.3 @ARGV = >perl 551404.pl -float abc Value "abc" invalid for option float (real number expected) Bad args` [download]	[reply] [d/l] [select]
Re^5: Issues w/ getOptions parsing options with pass_through enabled by Brawny1 (Initiate) on May 24, 2006 at 21:26 UTC
I need pass_through on as this is a wrapper script. I wish to have some arguments to be passed through while others are type checked.	[reply]