[openssl-dev] [openssl.org #4311] OpenSSL 1.1.0-pre3: quote PERL=$(PERL) in Makefiles

[Rainer Jung]

Am 10.05.2016 um 21:54 schrieb Richard Levitte via RT:
> I understand this part. What I'm questioning is the need to set PERL to
> "/usr/bin/env perl" to begin with. It's practically not different at all from
> setting it to just "perl", all this does is that any time the environment
> variable PERL is used to run a perl script is to have an extra process between
> the shell and perl itself that will simply pass along the exact environment
> that it got from the shell. In effect, any time the environment variable PERL
> with your assignment is used to run a script (assuming the quoting you
> suggest), i.e.:
>
> $PERL blah.pl
>
> it would expand to this:
>
> /usr/bin/env perl blah.pl
>
> If it's only assigned "perl", the command would expand to this:
>
> perl blah.pl
>
> perl itself literally gets the exact same environment in both cases.

I agree.

> Mind you, I did read your reasoning around #! in scripts. Unfortunately, that
> reasoning is flawed, that won't be affected by the environment variable PERL.

I had to rad my ticket again, and actually this is the only reason for 
the ticket: the following perl scripts are generated from .in files 
during building OpenSSL and get installed and executed later in another 
environment:

- c_rehash
- CA.pl
- tsget

All of them contain in the .in file the magic header:

#!{- $config{perl} -}

IMHO $config{perl} - detected and set during config and Configure from 
the PERL env var and as a fallback from the PATH - is used as the perl 
during build time and also put into the scripts for use on the target 
system.

But those two perl paths should be defined independently from each other.

You say the reasoning is flawed, but to me it looks like:

- config checks whether the PERL env var is set. If not it searches for 
a perl in the path and sets the PERL env var to that one.

- config calls Configure

- Configure sets $config{perl} from the PERL env var

- the scripts c_rehash, CA.pl and tsget are generated from their .in 
files and their first line

#!{- $config{perl} -}

is replaced by #!$PERL (with $PERL resolved).

I'd love if I were wrong and there would already be a way to set the 
perl for those scripts independently from the one used for the build 
process. If you think that demand is too specific, I can live with 
patching the scripts myself. But IMHO it would be nice not to enforce 
the same restrictions on the build procedure perl to the runtime perl 
for those simple scripts. For the build procedure it should be the 
required 5.10 with modules etc. For the three scripts typically the 
platform perl would suffice.

Regards,

Rainer