First question: what do you mean by "it broke"? Does it give an error message, or just give incorrect behaviour?

By default, perl will include a filename and line number on fatal errors unless they terminate in a newline. You can also modify the script to make a fatal error give a full stack trace in most cases, by adding something like this just after the shebang line:

BEGIN { use Carp; $SIG{__DIE__} = sub { Carp::confess(@_) } }
[download]

If the script is completing without a fatal error, but giving incorrect behaviour, you can insert this just after the shebang line to get a list of the paths to all modules that were loaded up to the point the script finishes:

END { print for values %INC }
[download]

That SIG DIE line can be replaced with

use Carp::Always;
[download]

Assuming you first install the module, of course.

G'day schwende,

I am dealing with a script that broke, after an os upgrade ... Any ideas are welcome

I'm not a Web programmer, never written a CGI program, so I'll just offer a few general ideas ... hoping they're welcome. :-)

As strongly cautioned by Fletch:

If you're doing anything serious with Perl you DO NOT want to use the OS' perl as that way lies much pain. Doing so couples you tightly to the OS' upgrade schedule for both the language and (if you're using its package manager for them) CPAN modules.

Many of us have learnt the hard way not to meddle with the system Perl on Unix systems. Much less pain to roll your own that you can control and freely experiment with, without risking breaking the system Perl, and without the risk of OS upgrades to the system Perl breaking your production systems. The same basic arguments apply to Python and other scripting languages BTW.

All the other cgi scripts work fine, but 1.

Anything stand out as different in the one that doesn't work? Do they all use CGI.pm? I ask because CGI.pm is no longer in the Perl core (the last Perl core that included it was perl v5.20). Posting representative code snippets from the one that doesn't work vs the many that do might provoke a useful response.

See also Re^9: XML tags using perl CGI by hippo, which mentions a few low-fat CGI modules that are preferable to CGI.pm nowadays.

👁️🍾👍🦟

Re: os upgrade breaks cgi is the better long answer.

Normally the error logs of your webserver should already include those messages.

Many CGIs can also meaningfully be started from the command line to see if they even compile. Compare the two installations for differences.

Of course, like already stated by hv we need to know "what it broke means" to avoid more guess work.

use CGI::Carp qw(fatalsToBrowser)