Skip Menu |
 

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

Report information
The Basics
Id: 82129
Status: open
Priority: 0/
Queue: MooseX-Getopt

People
Owner: ether [...] cpan.org
Requestors: RIchard.Scire [...] Mozelle.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.47
Fixed in: (no value)



Subject: MooseX-getopt-basic doesn't raise an error when unknow options or ambiguous options specified on command line
Download (untitled) / with headers
text/plain 777b
When an unknown option is specified on the command line, no error is given nor is the option added to extra_argv. If ambiguous options are entered, no errors are issued and in both cases the program continues. Examples H:\Metrics> perl test.pl -debug -database PROD -unknown Debug: 1; DB: PROD Unused params: H:\Metrics> perl test.pl -d Debug: 0; DB: DEV Unused params: Solution? Locally, I changed the function _getopt_spec_warnings from sub _getopt_spec_warnings { } to sub _getopt_spec_warnings { my ($self, @warnings) = @_; die @warnings, "\n"; } And to the correct results H:\Metrics> perl test.pl -debug -database PROD -unknown Unknown option: unknown H:\Metrics> perl test.pl -d Option d is ambiguous (database, debug)
Subject: TestGetOpts.pm
Download TestGetOpts.pm
text/x-perl 499b
package TestGetOpts; use Moose; with 'MooseX::Getopt::Basic'; use strict; use warnings; no warnings qw(uninitialized); ## no critic qw(ProhibitNoWarnings) use Carp; has 'debug' => ( is => 'rw', isa => 'Bool', default => 0, documentation => 'hidden', ); has 'database' => ( is => 'rw', isa => 'Str', default => 'DEV', documentation => 'The database', ); 1;
Subject: test.pl
Download test.pl
text/x-perl 286b
#! use strict; use warnings; use Carp; use TestGetOpts; my $OPTS = TestGetOpts->new_with_options(); my $debug = $OPTS->debug; my $database = $OPTS->database; print "Debug: $debug; DB: $database\n"; print "Unused params: " . join(', ', @{$OPTS->extra_argv}) . "\n";
Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknow options or ambiguous options specified on command line
Date: Thu, 20 Dec 2012 09:17:47 -0800
To: "Richard S. Scire via RT" <bug-MooseX-Getopt [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
Download (untitled) / with headers
text/plain 447b
On Wed, Dec 19, 2012 at 11:21:52PM -0500, Richard S. Scire via RT wrote: Show quoted text
> When an unknown option is specified on the command line, no error is > given nor is the option added to extra_argv. > > If ambiguous options are entered, no errors are issued and in both > cases the program continues.
This is by design, but it would certainly be useful to have options to configure your class to detect or reject unknown things on @ARGV if desired.
Subject: RE: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Thu, 20 Dec 2012 12:55:30 -0500
To: <bug-MooseX-Getopt [...] rt.cpan.org>
From: "Richard S. Scire" <Richard.Scire [...] Mozelle.com>
Download (untitled) / with headers
text/plain 1.7k
Hi, Thanks for your response. Unless there is some other way of detecting these issues, the current design leaves your application in a bad way. If I can't tell that an ambiguous option was entered, the application will proceed with the desired option not set and could yield invalid results. The same is true with unrecognized options, if it is a misspelling, then again, the desired behavior will not happen and there is no way to le the user know. If there was a way to capture that information so I could process it myself, that would be fine. I would have expected unrecognized options to be captured in the extra_argv variable but they just disappear into the ether. If there is a way to detect either of these problems, please let me know. If not, given the possible serious effect on the application's processing, what was the intent behind not allowing the app to check on the status of the getopt call? Thanks, Rich Show quoted text
-----Original Message----- From: Karen Etheridge via RT [mailto:bug-MooseX-Getopt@rt.cpan.org] Sent: Thursday, December 20, 2012 12:18 PM To: RIchard.Scire@Mozelle.com Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line <URL: https://rt.cpan.org/Ticket/Display.html?id=82129 > On Wed, Dec 19, 2012 at 11:21:52PM -0500, Richard S. Scire via RT wrote:
> When an unknown option is specified on the command line, no error is > given nor is the option added to extra_argv. > > If ambiguous options are entered, no errors are issued and in both > cases the program continues.
This is by design, but it would certainly be useful to have options to configure your class to detect or reject unknown things on @ARGV if desired.
Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Sat, 22 Dec 2012 02:08:42 -0800
To: "Richard S. Scire via RT" <bug-MooseX-Getopt [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
On Thu, Dec 20, 2012 at 12:55:54PM -0500, Richard S. Scire via RT wrote: Show quoted text
> If there was a way to capture that information so I could process it myself, that would be fine. I would have expected unrecognized options to be captured in the extra_argv variable but they just disappear into the ether. > > If there is a way to detect either of these problems, please let me know. If not, given the possible serious effect on the application's processing, what was the intent behind not allowing the app to check on the status of the getopt call?
I caught up on sleep and re-read this ticket more closely... The features you want are in the Getopt/NoGetopt attribute traits, rather than in the role that is applied to your class directly. So, you can do: with 'MooseX::Getopt::Strict'; has option_attr => ( ..., traits = ['Getopt'] ); has nooption_attr => ( ... ); (that is, explicitly mark the attributes you want to be available on the command line), or: with 'MooseX::Getopt'; has option_attr => ( ... ); has nooption_attr => ( ..., traits = ['NoGetopt'] ); ...to accept all attributes on the command line *except* those you explicitly mark as no-option. Personally, I like using ::Strict, so I can apply other roles to my class and not have those roles have to worry about marking its private attributes as NoGetopt. In either case (so long as you don't encounter a fatal error*), extra_argv should contain everything left over after parsing data into attributes. Any examples demonstrating otherwise will be gratefully accepted as new tests to verify subsequent fixes against :) If the attribute has the NoGetopt trait (either by not having the Getopt trait in example 1, or by having the NoGetopt trait in example 2) and it is seen on the command line, you'll get a fatal error, unless you tell Getopt::Long to pass through unrecognized options - you can do this in two ways -- one of which wasn't fully documented, which I've corrected in this commit: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/MooseX-Getopt.git;a=commitdiff;h=edd79c6fb9ebccd48ac7e3fec200468004fe6f5e
Sorry, docs were a bit fuzzy here; some improvement will be seen in the next release.
Subject: RE: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Sun, 23 Dec 2012 07:56:29 -0500
To: <bug-MooseX-Getopt [...] rt.cpan.org>
From: "Richard S. Scire" <Richard.Scire [...] Mozelle.com>
Download (untitled) / with headers
text/plain 2.9k
Hi, Thanks for the information. Unfortunately, when I use MooseX::Getopt::Strict, I lose the use of 'MooseX::Getopt::Basic and I get GLD even though I use Basic in order to avoid using GLD. So, even adding the Getopt trait to my attributes but not using Strict because I don’t want the GLD functionality, the incorrect and ambiguous options are ignored. Again, this leaves my application in the situation where I can't tell whether the user has entered the command line options correctly. Thanks, Rich Show quoted text
-----Original Message----- From: Karen Etheridge via RT [mailto:bug-MooseX-Getopt@rt.cpan.org] Sent: Saturday, December 22, 2012 5:09 AM To: RIchard.Scire@Mozelle.com Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line <URL: https://rt.cpan.org/Ticket/Display.html?id=82129 > On Thu, Dec 20, 2012 at 12:55:54PM -0500, Richard S. Scire via RT wrote:
> If there was a way to capture that information so I could process it myself, that would be fine. I would have expected unrecognized options to be captured in the extra_argv variable but they just disappear into the ether. > > If there is a way to detect either of these problems, please let me know. If not, given the possible serious effect on the application's processing, what was the intent behind not allowing the app to check on the status of the getopt call?
I caught up on sleep and re-read this ticket more closely... The features you want are in the Getopt/NoGetopt attribute traits, rather than in the role that is applied to your class directly. So, you can do: with 'MooseX::Getopt::Strict'; has option_attr => ( ..., traits = ['Getopt'] ); has nooption_attr => ( ... ); (that is, explicitly mark the attributes you want to be available on the command line), or: with 'MooseX::Getopt'; has option_attr => ( ... ); has nooption_attr => ( ..., traits = ['NoGetopt'] ); ...to accept all attributes on the command line *except* those you explicitly mark as no-option. Personally, I like using ::Strict, so I can apply other roles to my class and not have those roles have to worry about marking its private attributes as NoGetopt. In either case (so long as you don't encounter a fatal error*), extra_argv should contain everything left over after parsing data into attributes. Any examples demonstrating otherwise will be gratefully accepted as new tests to verify subsequent fixes against :) If the attribute has the NoGetopt trait (either by not having the Getopt trait in example 1, or by having the NoGetopt trait in example 2) and it is seen on the command line, you'll get a fatal error, unless you tell Getopt::Long to pass through unrecognized options - you can do this in two ways -- one of which wasn't fully documented, which I've corrected in this commit: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=gitmo/MooseX-Getopt.git;a=commitdiff;h=edd79c6fb9ebccd48ac7e3fec200468004fe6f5e
Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Sun, 23 Dec 2012 09:19:32 -0800
To: "Richard S. Scire via RT" <bug-MooseX-Getopt [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
On Sun, Dec 23, 2012 at 07:57:02AM -0500, Richard S. Scire via RT wrote: Show quoted text
> Thanks for the information. Unfortunately, when I use MooseX::Getopt::Strict, I lose the use of 'MooseX::Getopt::Basic and I get GLD even though I use Basic in order to avoid using GLD. > > So, even adding the Getopt trait to my attributes but not using Strict because I don???t want the GLD functionality, the incorrect and ambiguous options are ignored. Again, this leaves my application in the situation where I can't tell whether the user has entered the command line options correctly.
Yes, in order to reject all unknown options, you need to use MooseX::Getopt::Strict, which brings in ::GLD. ::Basic really is Basic, I'm afraid. The actual code in MooseX::Getopt::Strict is quite small, so you could either apply this yourself after applying ::Basic, or create a new ::Basic::Strict role which does this for you. Why do you want to use Basic rather than GLD? It's pretty rare to see this, so I'm curious what about GLD you don't like.
Subject: RE: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Sun, 23 Dec 2012 12:41:24 -0500
To: <bug-MooseX-Getopt [...] rt.cpan.org>
From: "Richard S. Scire" <Richard.Scire [...] Mozelle.com>
Download (untitled) / with headers
text/plain 1.9k
Hi, I prefer to use long options with the - rather than -- prefix. DLG forces you to use the -- prefix unless you turn off bundling and passing no_bundling to the GLD constructor doesn't seem to work. As for basic, I'm wondering what design objective was served by causing errors in the command line to be ignored? It seems the warnings are generated if there is an exception, but not if there are just warnings. Again, I'd be happy with the ability to check the warnings but they are both ignored and hidden so I can’t verify my command line. Thanks, Rich Show quoted text
-----Original Message----- From: Karen Etheridge via RT [mailto:bug-MooseX-Getopt@rt.cpan.org] Sent: Sunday, December 23, 2012 12:20 PM To: RIchard.Scire@Mozelle.com Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line <URL: https://rt.cpan.org/Ticket/Display.html?id=82129 > On Sun, Dec 23, 2012 at 07:57:02AM -0500, Richard S. Scire via RT wrote:
> Thanks for the information. Unfortunately, when I use MooseX::Getopt::Strict, I lose the use of 'MooseX::Getopt::Basic and I get GLD even though I use Basic in order to avoid using GLD. > > So, even adding the Getopt trait to my attributes but not using Strict because I don???t want the GLD functionality, the incorrect and ambiguous options are ignored. Again, this leaves my application in the situation where I can't tell whether the user has entered the command line options correctly.
Yes, in order to reject all unknown options, you need to use MooseX::Getopt::Strict, which brings in ::GLD. ::Basic really is Basic, I'm afraid. The actual code in MooseX::Getopt::Strict is quite small, so you could either apply this yourself after applying ::Basic, or create a new ::Basic::Strict role which does this for you. Why do you want to use Basic rather than GLD? It's pretty rare to see this, so I'm curious what about GLD you don't like.
Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Sun, 23 Dec 2012 10:47:47 -0800
To: "Richard S. Scire via RT" <bug-MooseX-Getopt [...] rt.cpan.org>
From: Karen Etheridge <ether [...] cpan.org>
Download (untitled) / with headers
text/plain 1.2k
On Sun, Dec 23, 2012 at 12:41:53PM -0500, Richard S. Scire via RT wrote: Show quoted text
> I prefer to use long options with the - rather than -- prefix. DLG forces you to use the -- prefix unless you turn off bundling and passing no_bundling to the GLD constructor doesn't seem to work.
Do you mean the Getopt::Long::Descriptive constructor? It's not constructed directly - parameters can be set with Getopt::Long::Configure, by pre-loading Getopt::Long::Configure with particular import options, or by passing a parameter to MooseX::Getopt::GLD. You should be able to turn off bundling here and achieve the right set of config options you need. It would be helpful if you could provide a short class and command line option string that demonstrates your usecase - I have been unable to construct any sort of working example that seems to use the Getopt config options you want (e.g. I don't see how to get plain old Getopt::Long to reject unknown options when using single dashes to specify them). Show quoted text
> As for basic, I'm wondering what design objective was served by causing errors in the command line to be ignored?
It is presumed that if the other behaviour is desired, then the user will use ::Strict, or twiddle with the Getopt::Long options before parsing the option string.
Subject: RE: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line
Date: Sun, 23 Dec 2012 18:15:13 -0500
To: <bug-MooseX-Getopt [...] rt.cpan.org>
From: "Richard S. Scire" <Richard.Scire [...] Mozelle.com>
Show quoted text
-----Original Message----- From: Karen Etheridge via RT [mailto:bug-MooseX-Getopt@rt.cpan.org] Sent: Sunday, December 23, 2012 1:48 PM To: RIchard.Scire@Mozelle.com Subject: Re: [rt.cpan.org #82129] MooseX-getopt-basic doesn't raise an error when unknown options or ambiguous options specified on command line <URL: https://rt.cpan.org/Ticket/Display.html?id=82129 > On Sun, Dec 23, 2012 at 12:41:53PM -0500, Richard S. Scire via RT wrote:
> I prefer to use long options with the - rather than -- prefix. DLG forces you to use the -- prefix unless you turn off bundling and passing no_bundling to the GLD constructor doesn't seem to work.
Do you mean the Getopt::Long::Descriptive constructor? It's not constructed directly - parameters can be set with Getopt::Long::Configure, by pre-loading Getopt::Long::Configure with particular import options, or by passing a parameter to MooseX::Getopt::GLD. You should be able to turn off bundling here and achieve the right set of config options you need. I’ve tried setting no_bundling using Configure but something in the MooseX::Getopt::* set of classes turns bundling back on later so there is no way for me to turn it off and have stay turned off. I don’t actually call MooseX::Getopt::GLD, I call my class with the new_with_options constructor and pass the no_bundling option but as I said earlier, somewhere, bundling gets turned back on. It would be helpful if you could provide a short class and command line option string that demonstrates your use case - I have been unable to construct any sort of working example that seems to use the Getopt config options you want (e.g. I don't see how to get plain old Getopt::Long to reject unknown options when using single dashes to specify them). I attached the 2 program files (test.pl and TestGetOpts.pm) to the ticket when I submitted it. It your run test.pl with the arguments shown in the body of the ticket, you should be able to see what my issues are. Getopt::Long will reject unknown arguments by default, since bundling is off by default. As you can see from the output, the bad command arguments are being rejected but for some reason, the function used to process the warnings, $class->_getopt_spec_warnings is empty causing the errors to be ignored and passing bad information back to the app. In the ticket I showed what I added to that function to make it work. Obviously, there are other ways it could work, it could die or it could set a variable with the bad options so the app can at least know there were some.
> As for basic, I'm wondering what design objective was served by causing errors in the command line to be ignored?
It is presumed that if the other behaviour is desired, then the user will use ::Strict, or twiddle with the Getopt::Long options before parsing the option string. This seems like such a simple thing to fix and the consequences of not fixing it are that this class is not usable by itself since there is no way to detect the errors I described. It doesn’t seem reasonable that I should have to fool with the command like before calling the command line processor.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.