[patch] GetOpt::Std::getopt() doesnt set value of valueless optio ns to 1.

[Yves Orton]

The pod for GetOpt::Std::getopt() from 5.8.x says

"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."

The key phrase being "to the value of the argument if an argument is
expected, or 1 otherwise", now if you interpret that the way you would
interpret what is said in the 5.6.1 release ".. to the value of the
argument, or 1 if no argument." then the code currently does not do the
right thing. If this is not the correct way to interperate it then this
represents a behaviour change without deprecation from 5.6.1 to 5.8.x.
Either way I'd say the documentation is misleading and should change. I
havent included a patch for the POD yet as I dont know what is correct. I
personally lean towards either

'...to the value of the argument if one is provided, or 1 otherwise.'

or to

'...to the value of the argument if one is provided, or undef otherwise'

I dont really see what the point is of putting "if an argument is expected"
as all options handled by getopt() are expected to have a value, and in fact
it will assume that a second switch following a first without a value is in
fact the value. IE: getopt('xy') on perl foo -x -y will set $opt_x to be
'-y', and if called with perl foo -x will set $opt_x to be undef. Actually I
would add a warning to the POD that says that getopt() should not be called
with valueless arguments.

Below is a patch that makes the 5.8.x version compliant with the intent
expressed by the 5.6.1 documentation.

Cheers,
yves

--- e:\perl-5.8.x\lib\GetOpt\Std.pm.orig 2003-11-17
18:33:03.322500000 +0100
+++ e:\perl-5.8.x\lib\GetOpt\Std.pm 2003-11-17 18:34:40.322500000 +0100
@@ -108,10 +108,10 @@
$rest = shift(@ARGV);
}
if (ref $hash) {
- $$hash{$first} = $rest;
+ $$hash{$first} = defined $rest ? $rest : 1;
}
else {
- ${"opt_$first"} = $rest;
+ ${"opt_$first"} = defined $rest ? $rest : 1;
push( @EXPORT, "\$opt_$first" );
}
}

[Ronald J Kimball]

On Mon, Nov 17, 2003 at 05:55:02PM -0000, Orton, Yves wrote:

> I dont really see what the point is of putting "if an argument is expected"
> as all options handled by getopt() are expected to have a value, and in fact
> it will assume that a second switch following a first without a value is in
> fact the value. IE: getopt('xy') on perl foo -x -y will set $opt_x to be
> '-y', and if called with perl foo -x will set $opt_x to be undef.

Not all options handled by getopt() are expected to have a value. With
getopt('xy'), -x and -y expect an argument, and all other options do not
expect an argument. perl foo -x -y -z will set $opt_x to '-y' and $opt_z
to 1.

> Actually I
> would add a warning to the POD that says that getopt() should not be called
> with valueless arguments.

The POD already says "Pass one argument which is a string containing all

switches that take an argument."

I believe the current behavior is correct, the current documentation is
correct, and this patch should not be applied.

Ronald