Skip Menu |

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

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

People
Owner: jv [...] cpan.org
Requestors: REHSACK [...] cpan.org
Cc:
AdminCc:

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



Subject: auto_(help|version) exits when Getopt::Long::Parser is used
I debugged a strange behaviour while creating some scripts using MooseX::App::Cmd and added a reaction to --help. MooseX::App::Cmd::Command checks for --configfile parameter using a new instance of Getopt::Long::Parser - and "$opt_parser->getoptions( 'configfile=s' => \$configfile );" exits the current process because of undefined default auto_help/auto_version and how GetOptionsFromArray() deals with those switches when they're not defined. I suggest to switch to a lazy initialization of $Getopt::Long::Parser::default_config to give developers a chance to change their wanted defaults ... Best regards, Jens
Sorry to hear this. Can you provide a small test program that shows this behaviour, preferrably w/o Moose?
CC: Ricardo SIGNES <rjbs [...] cpan.org>, Mark Gardner <mjgardner [...] cpan.org>
Subject: Re: [rt.cpan.org #79912] auto_(help|version) exits when Getopt::Long::Parser is used
Date: Fri, 28 Sep 2012 19:16:47 +0200
To: bug-Getopt-Long [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] cpan.org>
On 28.09.2012 16:36, Johan Vromans via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=79912 > > > Sorry to hear this. Can you provide a small test program that shows this > behaviour, preferrably w/o Moose?
For sure - see attachement. I'm sorry blaming Getopt::Long - but removing usage of GLD from test program restores expected behaviour. OTOH I couldn't find something in GLD which explains the premature exit (via HelpMessage()). Maybe GLD has to used from MX::App::Cmd with some flags? Best regards, Jens

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #79912] auto_(help|version) exits when Getopt::Long::Parser is used
Date: Fri, 28 Sep 2012 22:06:57 +0200
To: bug-Getopt-Long [...] rt.cpan.org
From: Johan Vromans <jvromans [...] squirrel.nl>
[Quoting Jens Rehsack via RT, on September 28 2012, 13:17, in "Re: [rt.cpan.org #79"] Show quoted text
> I'm sorry blaming Getopt::Long - but removing usage of GLD from test > program restores expected behaviour. OTOH I couldn't find something in > GLD which explains the premature exit (via HelpMessage()).
While, in fact, GLD is -- unknowingly -- the reason that it fails. GLD does: use Getopt::Long 2.33 (); The above 'use' registers that GL version 2.33 was required. Subsequence use of GetOptions will use this knowledge to enable the autohelp facility. As a consequence, in the test program: local @ARGV = qw(--help); # simulate behavior of MooseX::App::Cmd::Command my $parser2 = Getopt::Long::Parser->new( config => ['pass_through'] ); $parser2->getoptions( 'configfile=s' => \$configfile ); Since @ARGV is --help, GL calls its HelpMessage function. This calls pod2usage which prints nothing (there's no documentation) and exits. The best solution is to explicitly disable autohelp in the parser setup: my $parser2 = Getopt::Long::Parser->new( config => ['pass_through','no_auto_help'] ); Does this help? -- Johan
CC: Ricardo SIGNES <rjbs [...] cpan.org>, Mark Gardner <mjgardner [...] cpan.org>
Subject: Re: [rt.cpan.org #79912] auto_(help|version) exits when Getopt::Long::Parser is used
Date: Sat, 29 Sep 2012 13:36:35 +0100
To: bug-Getopt-Long [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] cpan.org>
2012/9/28 jvromans@squirrel.nl via RT <bug-Getopt-Long@rt.cpan.org>: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=79912 > > > [Quoting Jens Rehsack via RT, on September 28 2012, 13:17, in "Re: [rt.cpan.org #79"]
>> I'm sorry blaming Getopt::Long - but removing usage of GLD from test >> program restores expected behaviour. OTOH I couldn't find something in >> GLD which explains the premature exit (via HelpMessage()).
> > While, in fact, GLD is -- unknowingly -- the reason that it fails. > > GLD does: > > use Getopt::Long 2.33 (); > > The above 'use' registers that GL version 2.33 was required. > Subsequence use of GetOptions will use this knowledge to enable the > autohelp facility.
Well, it shouldn't be possible for a module to override program settings undesignedly. There is probably more than one way to reach that, but I hope you find a way suitable for Getopt::Long. Probably once initialized config doesn't become overwritten but extended/modified? Like attributes in Moose which have 2 information: is_set/is_clear and their value - even if the value is undefined ... Is there anything which can be recommended to Ricardo to prevent that behaviour in Getopt::Long when GLD is initialized? Show quoted text
> As a consequence, in the test program: > > local @ARGV = qw(--help); # simulate behavior of MooseX::App::Cmd::Command > my $parser2 = Getopt::Long::Parser->new( config => ['pass_through'] ); > $parser2->getoptions( 'configfile=s' => \$configfile ); > > Since @ARGV is --help, GL calls its HelpMessage function. This calls > pod2usage which prints nothing (there's no documentation) and exits. > > The best solution is to explicitly disable autohelp in the parser setup: > > my $parser2 = Getopt::Long::Parser->new( config => ['pass_through','no_auto_help'] ); > > Does this help?
You recommend the same this I extended in my bug-report to MooseX::App::Cmd (see https://github.com/mjgardner/moosex-app-cmd/issues). Hope that Mark reacts quickly. For the moment, I've added a patch to my local pkgsrc checkout, where all my used modules are installed from ... ... one "tiny" issue and finally work packages for 4 people - nice example how good CPAN authors collaborate. Thanks Johan. Best regards, Jens
Subject: Re: [rt.cpan.org #79912] auto_(help|version) exits when Getopt::Long::Parser is used
Date: Sat, 29 Sep 2012 14:53:12 +0200
To: bug-Getopt-Long [...] rt.cpan.org
From: Johan Vromans <jvromans [...] squirrel.nl>
[Quoting Jens Rehsack via RT, on September 29 2012, 08:36, in "Re: [rt.cpan.org #79"] Show quoted text
> Well, it shouldn't be possible for a module to override program > settings undesignedly.
Yes, this is an unfortunate sideeffect from using the required version number as a signal to do something. It seemed a good idea (actually, the least bad) idea at the time... Show quoted text
> Is there anything which can be recommended to Ricardo to prevent that > behaviour in > Getopt::Long when GLD is initialized?
Your test program is a bit tricky. use Getopt::Long qw(:config no_auto_help no_version ); use Getopt::Long::Descriptive (); By using :config no_auto_help no_version you assume that the available GL is of version 2.33 or higher. GLD explicitly requires 2.33 or higher. You can counter these with: use Getopt::Long 2.32 (); after use of GLD. But I'm not sure that's always feasible. Show quoted text
> ... one "tiny" issue and finally work packages for 4 people - nice > example how good CPAN authors collaborate.
I'm sorry for the inconvenience. -- Johan
CC: Ricardo SIGNES <rjbs [...] cpan.org>, Mark Gardner <mjgardner [...] cpan.org>
Subject: Re: [rt.cpan.org #79912] auto_(help|version) exits when Getopt::Long::Parser is used
Date: Sat, 29 Sep 2012 14:45:57 +0100
To: bug-Getopt-Long [...] rt.cpan.org
From: Jens Rehsack <rehsack [...] gmail.com>
2012/9/29 jvromans@squirrel.nl via RT <bug-Getopt-Long@rt.cpan.org>: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=79912 > > > [Quoting Jens Rehsack via RT, on September 29 2012, 08:36, in "Re: [rt.cpan.org #79"]
>> Well, it shouldn't be possible for a module to override program >> settings undesignedly.
> > Yes, this is an unfortunate sideeffect from using the required version > number as a signal to do something. It seemed a good idea (actually, > the least bad) idea at the time... >
>> Is there anything which can be recommended to Ricardo to prevent that >> behaviour in >> Getopt::Long when GLD is initialized?
> > Your test program is a bit tricky. > > use Getopt::Long qw(:config no_auto_help no_version ); > use Getopt::Long::Descriptive (); > > By using :config no_auto_help no_version you assume that the available > GL is of version 2.33 or higher. > > GLD explicitly requires 2.33 or higher. > > You can counter these with: > > use Getopt::Long 2.32 (); > > after use of GLD. But I'm not sure that's always feasible.
Unfortunately not. This happens between (command-)plugins loading and Moose-Magic to initialize attributes from CLI and configfile. MooseX::App::Cmd should explicitly tell GL::Parser not to auto_ anything ... while digging for configfile option behind the scenes ... Show quoted text
>> ... one "tiny" issue and finally work packages for 4 people - nice >> example how good CPAN authors collaborate.
> > I'm sorry for the inconvenience.
Well, I meant it really positive. Thanks to CPAN we have the opportunity to talk about found issues and fix them and spread all necessary fixes over all affected modules. Try it for any other environment ... /Jens
Jens: We spoke about this bug in Lancaster, and I tried to reproduce it using the getopt1.pl program you used. It produces the same output on my machine whether or not I remove the Getopt::Long::Descriptive line. That output is "Hello world" I have installed Getopt::Long 2.39 and GLD 0.093. I know about the behavior of ->VERSION in Getopt::Long, and understand how a bug like the one you described *could* happen, but I can't reproduce this specific failure, so I have no specific failure to look at addressing for you. If you can provide further instructions for testing or reproducing the bug you describe, I will happily dig into them. Thanks! -- rjbs
One of the minor changes in 2.39 may have fixed this.