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: 31978
Status: open
Priority: 0/
Queue: Perl-Critic

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

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



Subject: "Use IO::Interactive::is_interactive() instead of -t" dubious?
Download (untitled) / with headers
text/plain 640b
$ echo "use strict; -t FOO" | perlcritic Use IO::Interactive::is_interactive() instead of -t at line 1, column 14. See page 218 of PBP. (Severity: 5) I have several problems with this critique. First of all, it's recommending a 0.0.3 module trading off whatever perceived bugs using -t might have with whatever actual bugs that module has. Looking at what is_interactive() does, I'm not sure I agree with it's algorithm either. Second, using -t isn't always about determining if we're interactive, as illustrated above. At best, only -t STDIN or STDOUT should be warned about. Finally, is this really an issue of highest severity?
Download (untitled) / with headers
text/plain 418b
On Fri Dec 28 20:31:03 2007, MSCHWERN wrote: Show quoted text
> First of all, it's recommending a 0.0.3 module trading off > whatever perceived bugs using -t might have with whatever actual > bugs that module has. Looking at what is_interactive() does, > I'm not sure I agree with it's algorithm either.
Yeah, it's doing the wrong thing by considering the presence of command line arguments to mean "not interactive". See 24823.
Download (untitled) / with headers
text/plain 565b
Yeah, many people have commented that PBP recommends several Conway modules that aren't fully baked yet. Hopefully, the Perl community will persuade Damian to fix those modules and/or submit patches to him. I can be convinced to lower the default severity on this to 4. I don't have a copy of PBP in front of me at the moment, but I think I originally set the severity to 5 because PBP demonstrated how -t can give the wrong answer in certain situations. But if is_interactive() is also wrong in some cases, then I suppose it is a wash. Good enough? -Jeff
Download (untitled) / with headers
text/plain 1.4k
On Tue Jan 01 00:01:21 2008, THALJEF wrote: Show quoted text
> Yeah, many people have commented that PBP recommends several Conway > modules that aren't fully baked yet. Hopefully, the Perl community will > persuade Damian to fix those modules and/or submit patches to him.
I'll take a swing at patching them. Show quoted text
> I can be convinced to lower the default severity on this to 4. I don't > have a copy of PBP in front of me at the moment, but I think I > originally set the severity to 5 because PBP demonstrated how -t can > give the wrong answer in certain situations.
Only if you mess around with *ARGV. I'm not entirely sure I agree with the logic of looking at ARGV vs STDIN to determine interactivity. One seems to be "is there input" and the other more "is there a human at the other end of the line?" Show quoted text
> But if is_interactive() is > also wrong in some cases, then I suppose it is a wash. > > Good enough?
There's the third part. The implication that -t means "you're checking to see if the program is being run interactively" only applies to STDIN, STDOUT and maybe ARGV. There's not much you can say about -t on any other filehandle. Granted, I haven't run into this case yet. I've been mentally classifying critics into those which are about straightforward less-than-optimal practice (2 arg open, bareword filehandles, not turning on strict) and those which speculate on the author's intent such as this one. The former are more definitive and usually of a higher severity.
Download (untitled) / with headers
text/plain 809b
On Tue Jan 01 16:57:33 2008, MSCHWERN wrote: Show quoted text
> I've been mentally classifying critics into those which are about > straightforward less-than-optimal practice (2 arg open, bareword > filehandles, not turning on strict) and those which speculate on the > author's intent such as this one. The former are more definitive and > usually of a higher severity.
That gives me an idea... we could ship your preferred configuration in the Perl-Critic distribution (just as we do for Damian). I know a lot of people respect your views and would agree with you on many points. So if you send your .perlcriticrc file to dev@perlcritic.tigris.org, we'll make sure it gets into the next release. If you have the time, maybe you could annotate the file to help explain to others the choices that you've made. -Jeff


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.