> On May 10, 2018, at 1:51 PM, Dave Jones <[email protected]> wrote:
> 
> 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

ExtUtils::MakeMaker should switch any #! it finds with the perl that invoked 
Makefile.PL as it installs it. The catch is that the #! has to match 
/^#!\S+perl/

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to