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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
