I'd say the short answer is "yes"

That's encouraging - thanks kcott

You've included completely unknown code with "use cPanelUserConfig;"

cPanelUserConfig is a cPanel module. It performs some magic with @INC so that user installed modules can be found by Perl. PDF::API2 is a module I have installed so without cPanelUserConfig we won't get very far. Pretty much every script I write server side has this so I can be pretty sure this is not the cause of the issue.

I'd move strict and warnings to the start of your code. Was there a reason for putting these in the middle of the script?

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. I'm sure there are proper terms that I don't know but by "head code" I mean the part of the code that sets thing up correctly such as the shebang, setting paths and bringing in modules to use. Everything below is what actually does the work of the script.

Your report suggests that you think PDF::API2 is the source of the problem, but you don't say why

Sorry - I should have explained that identical head code exists in all the other scripts on the site and they all run with taint mode on. It's only since I tried using PDF::API2 that I have had this problem and the error reports it as being in File which is used by PDF::API2 and not called by my script anywhere else.

I'm out of the office currently but will look at the other things you suggest a little later and try removing/substituting code until I find the exact cause of the issue.

"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. :-)

— Ken

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

... 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]

---

Give a man a fish:  <%-{-{-{-<

"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.

Hire me at Toby Ink Ltd or Join my OnlyFans