# New Ticket Created by "Paul Cochrane"
# Please include the string: [perl #40482]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40482 >
Hi,
This patch adds a new policy for the Parrot Perl::Critic tests, namely
to check that the shebang line doesn't use 'perl -w', rather 'use
warnings;' and that the shebang line doesn't use something unix
specific such as '#!/usr/bin/perl' and rather '#! perl'. Would it be
a good idea to group all of the code standards-related stuff into a
directory CodeStandards? As such, should I then make a patch for
CodeLayout::UseParrotCoda to go under CodeStandards::UseParrotCoda
instead? I'm also wondering what the policy is on svn Id keywords in
files, and whether or not the svn:keywords property is set to a
particular value. I don't think there's a standard or anything
defined for this yet. Should there be? If so, should I put a request
into RT?
TIA
Regards,
Paul
files affected:
lib/Perl/Critic/Policy/CodeStandards/CheckPerlShebang.pm
Index: lib/Perl/Critic/Policy/CodeStandards/CheckPerlShebang.pm
===================================================================
--- lib/Perl/Critic/Policy/CodeStandards/CheckPerlShebang.pm (revision 0)
+++ lib/Perl/Critic/Policy/CodeStandards/CheckPerlShebang.pm (revision 0)
@@ -0,0 +1,76 @@
+# $Id#
+package Perl::Critic::Policy::CodeStandards::CheckPerlShebang;
+
+use strict;
+use warnings;
+use Perl::Critic::Utils;
+use Perl::Critic::Violation;
+use base 'Perl::Critic::Policy';
+
+our $VERSION = '0.1';
+$VERSION = eval $VERSION; ## no critic
+
+my $minus_w_desc = q{Need to use 'perl -w' instead of 'use warnings;'};
+my $minus_w_expl = q{All perl source in parrot must 'use warnings;' not the older 'perl -w' usage};
+
+my $unix_desc = q{Found unix-specific perl shebang line};
+my $unix_expl = q{Perl source in parrot should use the platform-independent shebang line: #! perl};
+
+#----------------------------------------------------------------------------
+
+sub default_severity { return $SEVERITY_LOW }
+sub applies_to { return 'PPI::Document' }
+
+#----------------------------------------------------------------------------
+
+sub violates {
+ my ( $self, $elem, $doc ) = @_;
+
+ my @elements = $doc->children();
+
+ # look for the shebang line, if any
+ foreach my $element ( @elements) {
+ if ($element =~ m/^#! .* perl/xgs) {
+ # if the shebang line matches 'perl -w', report the violation
+ if ($element =~ m/perl \s* -w/xgs) {
+ my $sev = $self->get_severity();
+ return Perl::Critic::Violation
+ ->new( $minus_w_desc, $minus_w_expl, $element, $sev );
+ }
+ elsif ($element =~ m{/usr(/local)?/bin/perl}xgs) {
+ my $sev = $self->get_severity();
+ return Perl::Critic::Violation
+ ->new( $unix_desc, $unix_expl, $element, $sev );
+ }
+ else {
+ last; # shebang line ok; skip to the end of the elements
+ }
+ }
+ }
+
+ # we didn't find any dodgy shebang lines, so return with success
+ return;
+}
+
+1;
+
+__END__
+
+=head1 NAME
+
+Perl::Critic::Policy::CodeStandards::CheckPerlShebang
+
+=head1 DESCRIPTION
+
+Check to see if the old 'perl -w' shebang line is used to switch on
+warnings. Also check to see that the perl shebang line isn't unix-specific
+i.e. uses something like #!/usr/bin/perl instead of the cross-platform #! perl.
+
+=cut
+
+# Local Variables:
+# mode: cperl
+# cperl-indent-level: 4
+# fill-column: 100
+# End:
+# vim: expandtab shiftwidth=4:
