in reply to Passing switches through pl2bat scripts

Why doesn't this Windows .cmd script pick up the -z command line switch:

It does. Try the following code with the argument of -z passed through from the outside: 

@rem = '--*-Perl-*--
@echo off
perl -x "%~dpnx0" %*
goto endofperl
@rem ';
#!perl
use strict;
use warnings;
print "\$ARGV[$_]= $ARGV[$_]\n" for 0..$#ARGV;
use Getopt::Std;
my %opts = ();
getopt( 'z', \%opts);
print "exists z\n" if exists $opts{'z'};
print "defined z='$opts{'z'}'\n" if defined $opts{'z'};
print "\$opts{z} is true" if $opts{'z'};
__END__
:endofperl

[download]

You will see that the -z is correctly propagated from the batch wrapper into perl. You will also see that $opts{'z'} exists, but contains an undefined value. It looks like from the documentation this behaviour is incorrect, and that it should in fact set $opts{'z'} to be true in this situation. It also looks like this behaviour has been fixed in a later version of Getopt::Std. The 5.8.1 version doesnt have this problem, the 5.6.1 version does. UPDATE: No im wrong here, changes were made to this module between 5.6.1 and 5.8.1 but they dont cover this issue.

Incidentally the reason this worked in your second variant is because the second -z is being treated as the value for the first -z option. IOW, $opts{'z'} eq '-z' in the second case, and !defined $opts{'z'} and exists($opts{'z'}) is true in the first.

I feel entitled to be a little critical here. It didnt take long to determine this was a fault in Getopt::Std, nor to identify and fix the bug. Next time I suggest you be a bit more thorough in your testing and debugging. Also you may find that Getopt::Long while a bit intimidating to look at the first time actually is a more flexible and powerful tool for this job. It certainly wouldnt have left you as confused about this as Getop::Std has done.

HTH


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi

Replies are listed 'Best First'.
Re^2: Passing switches through pl2bat scripts
by PhilHibbs (Hermit) on Nov 18, 2003 at 09:54 UTC
    I feel entitled to be a little critical here. It didnt take long to determine this was a fault in Getopt::Std, nor to identify and fix the bug.
    Bug? The bug is in Getopt::Std, and I think it is worthy of disucssion. How do I take this further? I ought to inform the author or maintainer of the package. What's the ettiquette here? Should I just email the author, or should I subscribe to some kind of mailing list?
[reply]
Re: Re: Passing switches through pl2bat scripts
by flounder99 (Friar) on Nov 17, 2003 at 17:37 UTC
    The docs aren't wrong, just very confusing. See my comment above.

    --

    flounder

[reply]

      I beg to differ. The docs are wrong in one way or the other. Consider the 5.6.1 release of the module. It has this to say:

      The getopt() functions processes single-character switches with switch clustering. Pass one argument which is a string containing all switches that take an argument. For each switch found, sets $opt_x (where x is the switch name) to the value of the argument, or 1 if no argument. Switches which take an argument don't care whether there is a space between the switch and the argument.

      the 5.8.x version has this to say

      The getopt() function processes single-character switches with switch clustering. Pass one argument which is a string containing all switches that take an argument. For each switch found, sets $opt_x (where x is the switch name) to the value of the argument if an argument is expected, or 1 otherwise. Switches which take an argument don't care whether there is a space between the switch and the argument.

      So in 5.6.1 the documentation does not agree with the behaviour of the module at all. So somethings wrong. In 5.8.1 the documentation discusses a case that doesn't exist. There are no circumstances where there isnt a value expected for an argument being handled by getop(). So something is wrong with the documentation.

      IMO the most reasonable behaviour is that which PhillHibbs was expecting which is the one that the docs in the 5.6.1 release specify, namely that the option should be set to 1.

      However the more I read of Getopt::Std the less suitable I think it is for on trivial usage. Im glad I never wasted any of my real time using it, as I went straight for Getopt::Long.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

[reply]
[d/l]

In Section Seekers of Perl Wisdom