"cPanelUserConfig ..."

I don't really want to harp on cPanelUserConfig. Here's a few quick notes:

• I wasn't suggesting cPanelUserConfig was a problem; it was an unknown, so therefore a possible culprit.
• I followed your "cPanel" link. It seems that I'd need to create an account to learn more about cPanelUserConfig (or search the web for an unofficial copy). I wasn't prepared to do either, so it remains an "unknown" for me.
• cPanelUserConfig may be a handy shortcut, which is fine; however, your use of the lib pragma shows that you already know how to manipulate @INC, so it's not quite as absolutely essential as you may think.
• I'd aim to move from "... pretty sure this is not the cause ..." to "... 100% certain this is not the cause ...".

"As both strict and warnings operate for all the block regardless of where they are declared, ..."

No, that's incorrect. Here's a handful of examples that I threw together to demonstrate:

$ perl -e 'BEGIN { $x = 1 } use strict;'

$ perl -e 'use strict; BEGIN { $x = 1 }'
Global symbol "$x" requires explicit package name (did you forget to d
+eclare "my $x"?) at -e line 1.
BEGIN not safe after errors--compilation aborted at -e line 1.

$ perl -e 'local $x; use strict;'

$ perl -e 'use strict; local $x;'
Global symbol "$x" requires explicit package name (did you forget to d
+eclare "my $x"?) at -e line 1.
Execution of -e aborted due to compilation errors.

$ perl -e 'use strict; local $x; no strict "vars";'
Global symbol "$x" requires explicit package name (did you forget to d
+eclare "my $x"?) at -e line 1.
BEGIN not safe after errors--compilation aborted at -e line 1.

$ perl -e 'use strict; no strict "vars"; local $x;'

$
[download]

"... the error reports it as being in File ..."

Actually, the error reports ".../IO/File.pm" which is the core module IO::File. I seem to recall that you were stuck with a fairly early version of Perl by your ISP; although, I do think IO::File would have been available in whatever early version that was:

$ corelist IO::File

Data for 2022-05-27
IO::File was first released with perl 5.00307
[download]

"... which is used by PDF::API2 and not called by my script anywhere else."

You don't necessarily need to have a "use IO::File;" statement. Consider these two:

$ perl -E 'print("Hello, world!\n"); say $INC{"IO/File.pm"};'
Hello, world!

$ perl -E 'STDOUT->print("Hello, world!\n"); say $INC{"IO/File.pm"};'
Hello, world!
/home/ken/perl5/perlbrew/perls/perl-5.36.0/lib/5.36.0/cygwin-thread-mu
+lti/IO/File.pm
[download]

"... will look at the other things you suggest a little later ..."

You might also like to try Carp::Always to get verbose backtraces. It can produce a lot of output, but could be a quick way to track down the source of the "Insecure dependency ..." message.

Good luck with your troubleshooting. :-)

The cPanelUserConfig module's sole purpose is to add the user-specific folders for a cPanel-based shared hosting site. On my cPanel-based shared hosting provider, this @INC populating can be accomplisehd via use cPanelUserConfig; or through a shebang of #!/usr/bin/perlml -- but it may be that other hosts are set up differently.

I was going to paste the contents of my provider's cPanelUserConfig.pm , since it's only a couple lines of code, but the copyright notice says I'd have to check the cPanel license terms to copy, which I didn't feel like doing. It's essentially a for-loop that adds predefined user-specific folders to @INC through unshift @INC, ... commands. This allows a perl script run on the shared hosting server to see the Perl modules that a given user has added through the cPanel interface that their host provides. Without this, users could not use the extra modules they have installed without manually inserting the various paths to user-installed scripts via @INC manipulation or multiple use lib ... statements. (Doing it manually could be fragile, because occasionally a shared hosting provider will change the path that leads up to where a user's home-directory, which could cause unexpected crashes in your scripts. Using the cPanelUserConfig or equivalent should make it more robust.)

So to the cPanel-based shared-hosting customer: You must include a line similar to the above to use the modules you install through cPanel -- but check your host's documentation, because they will be the canonical source for their specific implementation of cPanel.

And to the person replying to a question that includes use cPanelUserConfig; : This is just manipulating the @INC so that the script can see customer-installed scripts on a shared-hosting provider; it is not where you should be looking for bugs, and the questioner cannot just "remove" it, because otherwise the SSCCE they tried to provide won't work on their shared host.

(I decided to make this tangential post so that it can be used in the future, since it seems to come up once a year or so since I became a monk, and either the person asking the question or the person answering doesn't know what it does. This can be accessed in the future using [cPanelUserConfig Reference] )

My previous posts describing the purpose of cPanelUserConfig :

• Re^5: Error Message - PL_perl_destruct_level at /usr/lib64/perl5/DynaLoader.pm
• Re: GD and LWP giving 500 errors
• Re: When modules install in perl5
• Re: Apache/CGI fcould not use Spreadsheet::ParseExcel
• Re^2: Using eval: $@ isn't returning the error I expect

G'day pryrt,

++ Many thanks for this detailed explanation.

"... essentially a for-loop that adds predefined user-specific folders to @INC through unshift @INC, ... commands."

Given your mention of "specific implementation of cPanel", I imagine that it's not impossible for one of those predefined values to be tainted in some implementation(s). On that basis, and even if it's unlikely, it's still worth checking cPanelUserConfig to move from, as I put it, "pretty sure" to "100% certain".

Not posting your cPanelUserConfig.pm was the correct decision. I made much the same choice with not "search[ing] the web for an unofficial copy".

Changing the title, to facilitate searching for cPanelUserConfig here, was also a good move.

— Ken

Thank you pryrt for a far better explanation than I managed...

... both strict and warnings operate for all the block regardless of where they are declared ...

My understanding is that both strict and warnings are lexical.

c:\@Work\Perl\monks>perl

$x = 42;
print "$x \n";

print ">$y< \n";

use strict;
use warnings;

^Z
42
><
[download]

"As both strict and warnings operate for all the block regardless of where they are declared, I tend to use them to separate the head code from the actual mechanics of code."

This is not true, and you can verify it using:

$x = 1;
use strict;
$y = 2;
[download]

Perl will complain about the use of symbol $y, but not $x because $x was used before strictures.

Both strict and warnings use lexical scope, which means their effect starts where they're imported, and continues until the end of the block they were imported into (that is, the closing curly brace "}") or if they weren't imported into a block, until the end of the file.