On 05/10/2018 11:08 AM, Axb wrote:
On 05/10/2018 05:09 PM, Bill Cole wrote:
On 10 May 2018, at 3:21 (-0400), Axb wrote:
Why is this needed?
It is not possible to rely on /usr/bin/perl existing or being the
"right" perl on some platforms. Most obviously, Perl was removed long
ago from the FreeBSD base and the symlink at /usr/bin/perl was removed
from the perl5 port as of v5.20. On MacOS, /usr/bin/perl is Apple's
build of Perl, most recently v5.18, and historically it has been risky
business to make significant enhancements to that Perl world, so the
Perl installed for the purposes of SA might be in /usr/local,
/opt/local, /sw, or in a user homedir.
The shebang trick using /usr/bin/env is the simplest way to address
the issue of there being multiple interpreter worlds on a system for
different bespoke purposes. If $PATH is set correctly I don't see how
it is breaking on CentOS, although I guess it may be a consequence of
local::lib usage.
The less simple but more rigorous fix for the underlying issue is to
handle all scripts in the distribution in the same manner as the main
SA scripts: a .raw version in the source that gets run through
build/preprocessor with a suitable set of arguments. It is not clear
to me why we have a substantial collection of scripts (including the
test scripts) with a fixed interpreter path despite having a tool
whose functions include making that a build-time configurable. There
are even scripts which apparently are only ever run on sa-vm1 that
have this shebang line: #!/local/perl586/bin/perl
I see the point. Hopefully you can achieve that without breaking the
rest of us :)
RedHat compatible systems are used all over the place, so such breakage
can cause havoc.
I think the safest way to handle this is to leave the script as it was a
couple of days ago and on those systems that have perl in a different
place, launch it with the full path to perl with the script as an arg:
/usr/local/bin/perl masscheck.pl
