GWHAYWOOD has asked for the wisdom of the Perl Monks concerning the following question: 

$ cat test.pl:
#!/usr/bin/perl
use strict;
use warnings;
use POSIX qw( :unistd_h :sys_wait_h setsid WNOHANG );
POSIX::setsid() or die 'failed';

$ perlcritic --stern ./test.pl
Subroutine "setsid" not exported by "POSIX" at line...

[download]
What am I missing? Perl::Critic has certainly found examples of dubious technique on my part, but it also seems to have a few blind spots. What do the wise folks here think of Perl::Critic generally?

Replies are listed 'Best First'.
Re: Perl::Critic and the POSIX module.
by Fletch (Bishop) on Jan 26, 2022 at 16:10 UTC

    My hunch (without looking too deeply) is that POSIX is doing something that whichever module implements the exports policy for Perl::Critic doesn't recognize. It looks to be dynamically building its export list at compile/use time so the critic module isn't going to find an explicit @EXPORT or @EXPORT_OK package variable.

    And in general, Perl::Critic is going to set you on the right path most of the time. Even the cases where you don't agree with its default suggestions or comments it's probably something that you should at least be aware of and have made a conscious decision about (then you can ## no critic it and hush it up).

    Edit: Actually I can't reproduce either with same test source. Perl::Critic 1.140, POSIX 1.97, perl 5.34.0, OS X 10.15.7.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

[reply]
[d/l]
[select]
Re: Perl::Critic and the POSIX module.
by hippo (Archbishop) on Jan 26, 2022 at 16:30 UTC

    I am unable to reproduce your result.

    $ cat ct.pl
#!/usr/bin/perl 
use strict;
use warnings;
use POSIX qw( :unistd_h :sys_wait_h setsid WNOHANG );
POSIX::setsid() or die 'failed';
$ perl -cw ct.pl
ct.pl syntax OK
$ perl ct.pl
$ perlcritic --stern ct.pl
ct.pl source OK

    [download]

    This is with POSIX 1.38_03 and Perl::Critic 1.125.

    What do the wise folks here think of Perl::Critic generally?

    It's a useful tool both for the individual and for teams to apply consistent policies to code. No more or less than that.

    🦛

[reply]
[d/l]
Re: Perl::Critic and the POSIX module.
by cavac (Prior) on Jan 26, 2022 at 18:10 UTC

    What operating system and version are you on? Do you use the perl interpreter installed by your OS or did you compile it yourself?

    Also, and this might be a stupid question, POSIX::setsid() actually work on your particular installation? I haven't looked into it for more than a few minutes, but it looks like the POSIX module does all kind of weird dynamic stuff on compile time (and probably on runtime as well) depending on your OS. For example, the Makefile.PL is full of stuff like this:

    if ($^O ne 'MSWin32' && $^O ne 'freemint') {
    push @libs, qw(m posix cposix);
}

    [download]

    And even the .pm files have some nice stuff like:

    strerror  => 'errno => BEGIN { local $!; require locale; locale->import} my $e = $_[0] + 0; local $!; $! = $e; "$!"',

    or

    if ($^O eq 'MSWin32') {
    $default_export_tags{winsock_h} = [qw(

    [download]

    The astonishing thing here isn't that perlcritic has a hickup with stuff like that. It's astonishing that perlcritic gets it right more often than not under circumstance that are essentially "the module exports A B and C unless it is a full moon or the wind comes from the northeast, in which case the exports are A D and C and if you change the order of the exports the thing will instantly collapse into a black hole and take your project with it".

    perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'
[reply]
[d/l]
[select]
      Do you use the perl interpreter installed by your OS or did you compile it yourself?

      Yes, that could be part of the problem.
      It looks to me that /usr/bin/perl is being invoked to run "test.pl" ... I don't know which perl could be running "perlcritic".

      One other thing I notice is the OP doesn't explicitly state that the POSIX module does, in fact, export "setsid".
      For example, on Windows, "setsid" is not implemented, let alone exported.
      However, Perl::Critic doesn't build for me on Windows, so I don't get to see how the command perlcritic --stern ./test.pl reacts to that "test.pl" file on WIndows.

      Cheers,
      Rob
[reply]
[d/l]
Re: Perl::Critic and the POSIX module.
by GWHAYWOOD (Sexton) on Jan 27, 2022 at 09:56 UTC
    Thanks folks for the feedback, much appreciated. For the archives everything I'm using is stock Debian 10 (Buster): Perl 5.28.1 patched to hell and back, POSIX 1.84, Perl::Critic 1.132. It seemed to me also that Perl::Critic was having trouble divining the export intentions of the module so I'll stop worrying about this now. Thanks again. Oh, and yes. setsid() does actually work, has done in this application for five years and more, but I just thought I'd run it past Perl::Critic and now I almost wish I hadn't.
[reply]
[reply]

Back to Seekers of Perl Wisdom