Skip Menu |

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

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

People
Owner: jv [...] cpan.org
Requestors: cary.millsap [...] method-r.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 2.47



CC: Jeff Holt <jeff.holt [...] method-r.com>
Subject: Getopt::Long bug
Date: Mon, 14 Oct 2013 17:08:37 -0500
To: bug-Getopt-Long [...] rt.cpan.org
From: Cary Millsap <cary.millsap [...] method-r.com>
Here (below) is a test that shows Getopt::Long refusing to parse a valid real number value provided as input. The code succeeds with '--num=0.1' but fails with '--num=.1'. I am using GetOptions in my real code (same behavior) but have used GetOptionsFromString in the test case to make the test case easier to reproduce. This code succeeded on both inputs in version 2.38, but it is broken now in 2.42. use strict; use warnings; use Getopt::Long qw(GetOptionsFromString); use Data::Dumper; our %Opt = ( num => 0 ); our %Options = ( "num=f" => \$Opt{num} ); for (qw(0.1 .1)) { # both valid real number values my $arg = "--num=$_"; $Opt{num} = undef; GetOptionsFromString($arg, %Options); print "arg is '$arg'\n", Dumper(\%Opt), "\n\n"; } Here is my configuration info: $ sudo ppm query Getopt-Long +-------------+---------+-----------------------------------------------+------+ | name | version | abstract | area | +-------------+---------+-----------------------------------------------+------+ | Getopt-Long | 2.42 | Module to handle parsing command line options | site | | Getopt-Long | 2.38 | Extended processing of command line options | perl | +-------------+---------+-----------------------------------------------+------+ (2 packages installed matching 'Getopt-Long') $ perl -v This is perl 5, version 16, subversion 3 (v5.16.3) built for darwin-thread-multi-2level (with 1 registered patch, see perl -V for more detail) $ uname -a Darwin Cary-MacBook-Pro.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 Thank you for looking into it. Cary Millsap Method R Corporation Author of *The Method R Guide to Mastering Oracle Trace Data<http://amzn.to/173bpzg> *
Subject: Re: [rt.cpan.org #89513] AutoReply: Getopt::Long bug
Date: Mon, 14 Oct 2013 17:16:25 -0500
To: bug-getopt-long <bug-Getopt-Long [...] rt.cpan.org>
From: Cary Millsap <cary.millsap [...] method-r.com>
I have just confirmed that my test succeeds in version 2.41. The first release in which I've seen it break is 2.42. Cary Millsap Method R Corporation Author of *The Method R Guide to Mastering Oracle Trace Data<http://amzn.to/173bpzg> * On Mon, Oct 14, 2013 at 5:09 PM, Bugs in Getopt-Long via RT < bug-Getopt-Long@rt.cpan.org> wrote: Show quoted text
> > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Getopt::Long bug", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [rt.cpan.org #89513]. Your ticket is accessible > on the web at: > > https://rt.cpan.org/Ticket/Display.html?id=89513 > > Please include the string: > > [rt.cpan.org #89513] > > in the subject line of all future correspondence about this issue. To do > so, > you may reply to this message. > > Thank you, > bug-Getopt-Long@rt.cpan.org > > ------------------------------------------------------------------------- > Here (below) is a test that shows Getopt::Long refusing to parse a valid > real number value provided as input. The code succeeds with '--num=0.1' but > fails with '--num=.1'. I am using GetOptions in my real code (same > behavior) but have used GetOptionsFromString in the test case to make the > test case easier to reproduce. This code succeeded on both inputs in > version 2.38, but it is broken now in 2.42. > > use strict; > use warnings; > use Getopt::Long qw(GetOptionsFromString); > use Data::Dumper; > > our %Opt = ( num => 0 ); > our %Options = ( "num=f" => \$Opt{num} ); > > for (qw(0.1 .1)) { # both valid real number values > my $arg = "--num=$_"; > $Opt{num} = undef; > GetOptionsFromString($arg, %Options); > print "arg is '$arg'\n", Dumper(\%Opt), "\n\n"; > } > > Here is my configuration info: > > $ sudo ppm query Getopt-Long > > +-------------+---------+-----------------------------------------------+------+ > | name | version | abstract | > area | > > +-------------+---------+-----------------------------------------------+------+ > | Getopt-Long | 2.42 | Module to handle parsing command line options | > site | > | Getopt-Long | 2.38 | Extended processing of command line options | > perl | > > +-------------+---------+-----------------------------------------------+------+ > (2 packages installed matching 'Getopt-Long') > > $ perl -v > This is perl 5, version 16, subversion 3 (v5.16.3) built for > darwin-thread-multi-2level > (with 1 registered patch, see perl -V for more detail) > > $ uname -a > Darwin Cary-MacBook-Pro.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep > 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64 > > Thank you for looking into it. > > > Cary Millsap > Method R Corporation > Author of *The Method R Guide to Mastering Oracle Trace > Data<http://amzn.to/173bpzg> > * >
Thanks for your bug report. In 2.42 the format requirements for floating point numbers have been adjusted to meet the program documentation, internal comments, and common sense. As a result, .1 is no longer considered a valid number, there must be at least one digit before and after the decimal point. I hope it won't be too much of an inconvenience.
CC: Jeff Holt <jeff.holt [...] method-r.com>
Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Tue, 15 Oct 2013 08:30:54 -0500
To: "bug-Getopt-Long [...] rt.cpan.org" <bug-Getopt-Long [...] rt.cpan.org>
From: Cary Millsap <cary.millsap [...] method-r.com>
Johan, I respectfully disagree that this is an improvement in the spec. Values like '.1' are valid constants in Perl, C, Mathematica, bc, PHP, Java, JavaScript, and many other languages. in fact, I can't think of a language in which '.1' is *no*t a valid floating point literal. We've been relying on this [0-9]*\.[0-9]+ style of floating point specification in the command line interface of our commercial software for over ten years. I hope you will reconsider. If I can't convince you, then we're faced with either holding at 2.41 or maintaining our own private Getopt::Long. Thank you. Cary Show quoted text
> On Oct 15, 2013, at 2:44 AM, "Johan Vromans via RT" <bug-Getopt-Long@rt.cpan.org> wrote: > > <URL: https://rt.cpan.org/Ticket/Display.html?id=89513 > > > Thanks for your bug report. > In 2.42 the format requirements for floating point numbers have been adjusted to meet the program documentation, internal comments, and common sense. As a result, .1 is no longer considered a valid number, there must be at least one digit before and after the decimal point. > I hope it won't be too much of an inconvenience.
Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Tue, 15 Oct 2013 15:35:05 +0200
To: bug-Getopt-Long [...] rt.cpan.org
From: Johan Vromans <jvromans [...] squirrel.nl>
Show quoted text
> We've been relying on this [0-9]*\.[0-9]+ style of floating point > specification in the command line interface of our commercial > software for over ten years. I hope you will reconsider. If I can't > convince you, then we're faced with either holding at 2.41 or > maintaining our own private Getopt::Long.
Ok, hold at 2.41 and I'll see what I can do. Fortunately, rejecting .1 was a sideeffect of the changes in 2.42, not the goal :) -- Johan
CC: Jeff Holt <jeff.holt [...] method-r.com>
Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Tue, 15 Oct 2013 09:29:24 -0500
To: bug-Getopt-Long [...] rt.cpan.org
From: Cary Millsap <cary.millsap [...] method-r.com>
Thank you very much. Cary Millsap Method R Corporation Author of *The Method R Guide to Mastering Oracle Trace Data<http://amzn.to/173bpzg> * On Tue, Oct 15, 2013 at 8:35 AM, jvromans@squirrel.nl via RT < bug-Getopt-Long@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=89513 > >
> > We've been relying on this [0-9]*\.[0-9]+ style of floating point > > specification in the command line interface of our commercial > > software for over ten years. I hope you will reconsider. If I can't > > convince you, then we're faced with either holding at 2.41 or > > maintaining our own private Getopt::Long.
> > Ok, hold at 2.41 and I'll see what I can do. > > Fortunately, rejecting .1 was a sideeffect of the changes in 2.42, not > the goal :) > > -- Johan > > > >
CC: Jeff Holt <jeff.holt [...] method-r.com>
Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Tue, 9 Jun 2015 16:56:08 -0500
To: bug-getopt-long <bug-Getopt-Long [...] rt.cpan.org>
From: Cary Millsap <cary.millsap [...] method-r.com>
John, This is still an issue for us. We have noticed that there doesn't appear to be any progress as of 2.45. Is there any way we can help? Cary Millsap Method R Corporation Author of *Optimizing Oracle Performance <http://amzn.to/OM0q75>* and *The Method R Guide to Mastering Oracle Trace Data <http://amzn.to/173bpzg>* On Tue, Oct 15, 2013 at 9:29 AM, Cary Millsap <cary.millsap@method-r.com> wrote: Show quoted text
> Thank you very much. > > > Cary Millsap > Method R Corporation > Author of *The Method R Guide to Mastering Oracle Trace Data > <http://amzn.to/173bpzg>* > > > > On Tue, Oct 15, 2013 at 8:35 AM, jvromans@squirrel.nl via RT < > bug-Getopt-Long@rt.cpan.org> wrote: >
>> <URL: https://rt.cpan.org/Ticket/Display.html?id=89513 > >>
>> > We've been relying on this [0-9]*\.[0-9]+ style of floating point >> > specification in the command line interface of our commercial >> > software for over ten years. I hope you will reconsider. If I can't >> > convince you, then we're faced with either holding at 2.41 or >> > maintaining our own private Getopt::Long.
>> >> Ok, hold at 2.41 and I'll see what I can do. >> >> Fortunately, rejecting .1 was a sideeffect of the changes in 2.42, not >> the goal :) >> >> -- Johan >> >> >> >>
>
CC: Jeff Holt <jeff.holt [...] method-r.com>
Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Tue, 9 Jun 2015 18:20:30 -0500
To: bug-getopt-long <bug-Getopt-Long [...] rt.cpan.org>
From: Cary Millsap <cary.millsap [...] method-r.com>
John, We went ahead and made the mod that works for us. I changed a single byte of the $PAT_FLOAT constant (a '+' to a '*'). We added a new test file t/89513.t to confirm that both 0.1 and .1 (positive and negative) are processed correctly. Everything is attached to this note as a tar.gz. Cary Millsap Method R Corporation Author of *Optimizing Oracle Performance <http://amzn.to/OM0q75>* and *The Method R Guide to Mastering Oracle Trace Data <http://amzn.to/173bpzg>* On Tue, Jun 9, 2015 at 4:56 PM, Cary Millsap <cary.millsap@method-r.com> wrote: Show quoted text
> John, > > This is still an issue for us. We have noticed that there doesn't appear > to be any progress as of 2.45. Is there any way we can help? > > > Cary Millsap > Method R Corporation > Author of *Optimizing Oracle Performance <http://amzn.to/OM0q75>* and *The > Method R Guide to Mastering Oracle Trace Data <http://amzn.to/173bpzg>* > > > On Tue, Oct 15, 2013 at 9:29 AM, Cary Millsap <cary.millsap@method-r.com> > wrote: >
>> Thank you very much. >> >> >> Cary Millsap >> Method R Corporation >> Author of *The Method R Guide to Mastering Oracle Trace Data >> <http://amzn.to/173bpzg>* >> >> >> >> On Tue, Oct 15, 2013 at 8:35 AM, jvromans@squirrel.nl via RT < >> bug-Getopt-Long@rt.cpan.org> wrote: >>
>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=89513 > >>>
>>> > We've been relying on this [0-9]*\.[0-9]+ style of floating point >>> > specification in the command line interface of our commercial >>> > software for over ten years. I hope you will reconsider. If I can't >>> > convince you, then we're faced with either holding at 2.41 or >>> > maintaining our own private Getopt::Long.
>>> >>> Ok, hold at 2.41 and I'll see what I can do. >>> >>> Fortunately, rejecting .1 was a sideeffect of the changes in 2.42, not >>> the goal :) >>> >>> -- Johan >>> >>> >>> >>>
>>
>
Download Getopt-Long-2.4601.tar.gz
application/x-gzip 42.1k

Message body not shown because it is not plain text.

Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Wed, 10 Jun 2015 08:22:48 +0200
To: bug-Getopt-Long [...] rt.cpan.org
From: Johan Vromans <jvromans [...] squirrel.nl>
Show quoted text
> This is still an issue for us. We have noticed that there doesn't appear to > be any progress as of 2.45. Is there any way we can help?
Sorry, I thought I'd already fixed it... -- Johan
Thanks for the suggestion. Unfortunately that will allow illegal numbers like "e1", "-" and "" (yes, empty). I added a zero width positive look-ahead to prevent those from being accepted. The pattern now becomes use constant PAT_FLOAT => "[-+]?(?=[0-9.])[0-9_]*(\.[0-9_]+)?([eE][-+]?[0-9_]+)?"; I'll release this as 2.47. Thanks for the reminder. -- Johan
Please try 2.46_01 on CPAN to see if it's okay.
Subject: Re: [rt.cpan.org #89513] Getopt::Long bug
Date: Wed, 10 Jun 2015 16:27:09 -0500
To: bug-getopt-long <bug-Getopt-Long [...] rt.cpan.org>
From: Cary Millsap <cary.millsap [...] method-r.com>
Johan, We have installed 2.46_01 from CPAN, and everything is a-ok. Thank you! Cary On Wed, Jun 10, 2015 at 10:47 AM, Johan Vromans via RT < bug-Getopt-Long@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=89513 > > > Please try 2.46_01 on CPAN to see if it's okay. >