Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 38458
Status: resolved
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: mschwern [...] cpan.org
Cc:
AdminCc:

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



Subject: option dashifying bug?
I'm trying to add in a --pager switch to perlcritic and I noticed an odd behavior of the results from get_option(). I think the dashification at the end is doubling up dashes. 0 windhund /usr/local/src/CPAN/Perl-Critic-1.090$ perl -dw bin/perlcritic -1 --color --pager=less lib/Perl/Critic.pm Loading DB routines from perl5db.pl version 1.28 Editor support available. Enter h or `h h' for help, or `man perldebug' for more help. main::(bin/perlcritic:33): our $VERSION = '1.090'; DB<1> x @ARGV 0 '-1' 1 '--color' 2 '--pager=less' 3 'lib/Perl/Critic.pm' DB<2> c get_options main::get_options(bin/perlcritic:71): 71: my %opts = _parse_command_line(); DB<3> n main::get_options(bin/perlcritic:72): 72: _dispatch_special_requests( %opts ); DB<3> c 103 main::get_options(bin/perlcritic:103): 103: return %dashed_opts; DB<4> x \%opts 0 HASH(0x1ab8570) '-color' => 1 1 => 1 'color' => 1 'pager' => 'less' 'severity' => 1 DB<5> x \%dashed_opts 0 HASH(0x1ab8930) '--color' => 1 '-1' => 1 '-color' => 1 '-pager' => 'less' '-severity' => 1 Note how there's a --color (which is the default set in _parse_command_line()) and -color which is what was set on the command line. This duplication makes using the result from get_options() difficult without first running it through Perl::Critic->new and accessing it via the config object. This is a problem because I would like to open and use a pager before loading Perl::Critic, so any printing necessary before that point can use the pager. I might wind up with $options{pager} or $options{-pager} or $options{--pager}. What to do?
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Wed, 13 Aug 2008 22:46:55 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Michael G Schwern via RT wrote: Show quoted text
> I'm trying to add in a --pager switch to perlcritic and I noticed an odd > behavior of the results from get_option().
Don't get me started in the options stuff. You don't need to use double dashes for long options, single dashes will do. *sigh*
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Fri, 15 Aug 2008 14:29:38 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Elliot Shank via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=38458 > > > Michael G Schwern via RT wrote:
>> I'm trying to add in a --pager switch to perlcritic and I noticed an odd >> behavior of the results from get_option().
> > Don't get me started in the options stuff. You don't need to use double dashes for long options, single dashes will do. *sigh*
To be clear, I'm talking about a perlcritic command line option. Not a Perl::Critic->new() option. -- I am somewhat preoccupied telling the laws of physics to shut up and sit down. -- Vaarsuvius, "Order of the Stick" http://www.giantitp.com/comics/oots0107.html
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Fri, 15 Aug 2008 20:07:06 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Michael G Schwern via RT wrote: Show quoted text
> To be clear, I'm talking about a perlcritic command line option. Not a > Perl::Critic->new() option.
So am I.
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Sun, 17 Aug 2008 00:37:23 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Elliot Shank via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=38458 > > > Michael G Schwern via RT wrote:
>> To be clear, I'm talking about a perlcritic command line option. Not a >> Perl::Critic->new() option.
> > So am I.
I don't understand, perlcritic is documented to use --foo style arguments. -------------------------------- SYNOPSIS perlcritic [-12345 | --brutal | --cruel | --harsh | --stern | --gentle] [--severity number | name] [--profile file | --noprofile] [--top [ number ]] [--theme expression] [--include pattern] [--exclude pattern] [{-s | --single-policy} pattern] [--only | --noonly] [--profile-strictness {warn|fatal|quiet}] [--force | --noforce] [--statistics] [--statistics-only] [--count | -C] [--verbose {number | format}] [--color | --nocolor] [--pager pager] [--quiet] {FILE | DIRECTORY | STDIN} -- The past has a vote, but not a veto. -- Mordecai M. Kaplan
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Sun, 17 Aug 2008 03:27:50 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Michael G Schwern via RT wrote: Show quoted text
> I don't understand, perlcritic is documented to use --foo style arguments.
Actually, it accepts either single or double dashed versions. (This is well before I started on the project.) I changed the doc to encourage people to use the two dashes because I hate named options with single dashes.
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Sun, 17 Aug 2008 01:44:09 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Elliot Shank via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=38458 > > > Michael G Schwern via RT wrote:
>> I don't understand, perlcritic is documented to use --foo style arguments.
> > Actually, it accepts either single or double dashed versions. (This is well before I started on the project.) I changed the doc to encourage people to use the two dashes because I hate named options with single dashes.
Now I'm totally confused. Your first reply said "you don't need to use double dashes for long options, single dashes will do." What did that mean and how does it relate to the original ticket? -- 191. Our Humvees cannot be assembled into a giant battle-robot. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Sun, 17 Aug 2008 04:13:02 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Michael G Schwern via RT wrote: Show quoted text
> Queue: Perl-Critic Ticket <URL: > http://rt.cpan.org/Ticket/Display.html?id=38458 > > > Elliot Shank via RT wrote:
>> <URL: http://rt.cpan.org/Ticket/Display.html?id=38458 > >> >> Michael G Schwern via RT wrote:
>>> I don't understand, perlcritic is documented to use --foo style >>> arguments.
>> Actually, it accepts either single or double dashed versions. >> (This is well before I started on the project.) I changed the doc >> to encourage people to use the two dashes because I hate named >> options with single dashes.
> > Now I'm totally confused. Your first reply said "you don't need to > use double dashes for long options, single dashes will do." What did > that mean and how does it relate to the original ticket?
In other words, perlcritic -foo and perlcritic --foo mean the same thing. And you can't check before P::C is instantiated because we won't know what the value pulled from the configuration will be until after then.
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Sun, 17 Aug 2008 03:27:55 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Elliot Shank via RT wrote: Show quoted text
> In other words, > > perlcritic -foo > > and > > perlcritic --foo > > mean the same thing. > > And you can't check before P::C is instantiated because we won't know what the value pulled from the configuration will be until after then.
I think there's some confusion. This is not about -foo and --foo command line arguments. This is about the en-dashing code at the end of get_options() which indiscriminately adds a dash to everything even if it already has one. # I've adopted the convention of using key-value pairs for # arguments to most functions. And to increase legibility, # I have also adopted the familiar command-line practice # of denoting argument names with a leading dash (-). my %dashed_opts = map { ( "-$_" => $opts{$_} ) } keys %opts; return %dashed_opts; So the default -color set in _parse_command_line() becomes --color but a --color on the command line is -color DB<4> x \%dashed_opts 0 HASH(0x1ab88a0) '--color' => 1 '-color' => 1 '-severity' => undef which is awkward to work with. -- 100. Claymore mines are not filled with yummy candy, and it is wrong to tell new soldiers that they are. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Sun, 17 Aug 2008 05:58:44 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Mon, 18 Aug 2008 17:39:46 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Elliot Shank via RT wrote: Show quoted text
Looks sensible. This is largely moot since the -color => 1 default was eliminated from _parse_command_line(). -- Defender of Lexical Encapsulation
Subject: Re: [rt.cpan.org #38458] option dashifying bug?
Date: Mon, 18 Aug 2008 18:26:40 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
On Aug 18, 2008, at 5:41 PM, Michael G Schwern via RT wrote: Show quoted text
> Queue: Perl-Critic > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=38458 > > > Elliot Shank via RT wrote: > > Looks sensible. > > This is largely moot since the -color => 1 default was eliminated from > _parse_command_line().
Yes, I think that line should have never been there. For better or worse, the default values for all command-line options should only be in the OptionsProcessor. So revision 2675 is probably unnecessary now. I'll clean it up. -Jeff
This has been fixed on the trunk.