0

I can't find anyone that can help me fix this issue. after a recent centos update my CGI scrips that use:

#!/usr/local/cpanel/3rdparty/bin/perl

or

#!/usr/bin/perl

are trying to use an old perl version 5.16.3

but they should be using the current cpanel version 5.30.0

if i login to ssh and run

/usr/local/cpanel/3rdparty/bin/perl -v i get 5.30.0

so i need to edit the path that the shebang use and it to to /usr/local/cpanel/3rdparty/bin/perl

help ?

3
  • The path that you mention you'd like to use seem so be the same as the one you say it's using.
    – Kusalananda
    Commented May 1, 2020 at 14:14
  • ya :) but it's not .. when the script runs using the shebangs it uses some wierd 5.16.3 version as opposed to what it should be using so i figure that the path that the shebangs command use got edited during this server update
    – Neijek
    Commented May 1, 2020 at 14:20
  • No, the #!-line in the file is the interpreter it will use, assuming you don't invoke the scripts with an explicit interpreter. If you do, you can have anything in the #!-line, and it would not matter what that path said as it would be ignored.
    – Kusalananda
    Commented May 1, 2020 at 15:52

2 Answers 2

0

If you find that the #!-line in a Perl script does not seem to take effect (which seems to be the case here), then it's likely because the scripts are being invoked with an explicit interpreter, as in

perl somescript.pl

In this case, the #!-line would be completely ignored, and the actual perl binary used would be the first one found in $PATH.

If you can change the way that the scripts are being invoked, then you would ideally change that to drop the explicit perl command. This would make the #!-lines in the scripts take effect (assuming the scripts are executable).

Alternatively, you would arrange for the $PATH variable so that the first perl binary found is the one that you know that you want to use. For example, you may want to set

PATH=/usr/local/cpanel/3rdparty/bin:$PATH

for the environment in which the CGI script executes. This would solve the issue unless the invocation is with usr/bin/perl explicitly. Since there is no indication in the question what web server software or framework is in use, or how it's configured to run Perl scripts, that's all I can say.

-2

Found the fix:

in SSH as Root:

cd /usr/bin

rm -f perl

ln -s /usr/local/cpanel/3rdparty/bin/perl .

This sets the shebang for both

#!/usr/bin/perl

and

#!/usr/local/cpanel/3rdparty/bin/perl

to use the cpanel updated perl found in:

/usr/local/cpanel/3rdparty/bin/perl
2
  • Note that by manually removing the /usr/bin/perl executable and replacing it with a different perl executable, you have now likely broken other things on your setup.
    – Kusalananda
    Commented May 1, 2020 at 15:53
  • And the next time the perl package gets updated, it’ll fix the /usr/bin/perl file to be the packaged version and not the symlink into /usr/local/cpanel/...
    – jsbillings
    Commented May 1, 2020 at 19:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .