Skip Menu |

This queue is for tickets about the Getopt-Long CPAN distribution.

Report information
The Basics
Id: 120300
Status: resolved
Priority: 0/
Queue: Getopt-Long

People
Owner: Nobody in particular
Requestors: jim.avera [...] gmail.com
Cc: RIVY [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.48
Fixed in: 2.50



Subject: optional option value broken with
Optional option values don't (no longer?) seem to work if gnu_compat is in effect. The documentation says that the argument following an option which takes an optional value will only be used if it "does not look like a value command line option itself". The docs also say that if an optional value is not provided, then '' will be supplied for string options (0 for numerics). But with gnu_getopt enabled, none of this works: If a value _is_ supplied, it is not used but is left in @ARGV even though the following arg is a different valid argument. If a value is NOT supplied, the arg is not set to '' but is left undefined, i.e., the argument is just swallowed with no effect whatever. I'm pretty sure this is a regression, as some existing scripts stopped working recently because of this. #!/usr/bin/perl use strict; use warnings; use Data::Dumper; use Getopt::Long; @ARGV = (qw(-a avalue -b extra1 extra2 )); my ($a, $b); #Getopt::Long::Configure("gnu_getopt"); Getopt::Long::Configure(qw(gnu_compat)); my $r = GetOptions( "a:s" => \$a, "b" => \$b, ); die unless $r; print Data::Dumper->Dump([$a, $b, \@ARGV], ['a', 'b', 'argv']); die "ERROR(?) \$a is undef" unless defined($a); # dies here
From: jim.avera [...] gmail.com
Sorry about the typos. The problem (optional values not working) occurs if gnu_compat is configured, and nothing else.
This behaviour was changed in 2.48. I'm not quite sure if this is a regression or a bugfix. The program explicitly asks for GNU getopt compatibility. What would be the corresponding call to GNU getopt_long in a C-program?
Subject: Re: [rt.cpan.org #120300] optional option value broken with
Date: Mon, 20 Feb 2017 15:18:05 -0800
To: bug-Getopt-Long [...] rt.cpan.org
From: Jim Avera <jim.avera [...] gmail.com>
On Feb 20, 2017 11:38 AM, "Johan Vromans via RT" < bug-Getopt-Long@rt.cpan.org> wrote: <URL: https://rt.cpan.org/Ticket/Display.html?id=120300 > This behaviour was changed in 2.48. I'm not quite sure if this is a regression or a bugfix. It now silently swallows the option without doing anything. That can't be correct behavior, can it?
Sure, but what should it do? That's why I asked for a C example.
From: jim.avera [...] gmail.com
Show quoted text
> That's why I asked for a C example.
Is C library compat. really relevant this many years after Getopt::Long was released? Becoming more compatible with C at the cost of breaking compatibility with Perl (i.e. existing scripts) doesn't seem right IMO.
From: jim.avera [...] gmail.com
First things first: Make it do what the documentation says. In this case, the docs simply say that gnu_compat means the "--opt=" form is allowed and causes "opt" to get an empty value; otherwise "--opt=" causes an error. Since it doesn't mention any other effects, then gnu_compat should not change how the ("--opt", "value") form works, including if the vlaue is optional. _if_ a change in behavior is really desired (compatible or not), then change the docs at the same time, or better, publish proposed changed docs and get feedback; one way or another, try to not let code ever escape to the public unless it has matching pod content.
I've pushed a fix to github. Please test it. I've also added to the documentation of gnu_compat: Note that C<--opt value> is still accepted, even though GNU getopt_long() doesn't.
From: jim.avera [...] gmail.com
On Wed Feb 22 06:18:01 2017, JV wrote: Show quoted text
> I've pushed a fix to github. Please test it.
Sure. Where is it on github? Unfortunately I'm not github-literate. I tried searching github.com for "Getopt" and "Getopt_Long" and got a huge number of hits.
Sorry, I should have been more clear: https://github.com/sciurius/perl-Getopt-Long