perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [Patch mp2] Statically compiling mod_perl in httpd (take 2)
Date Wed, 23 Jun 2004 20:07:19 GMT
Philippe M. Chiasson wrote:
> Stas Bekman wrote:
>> Philippe M. Chiasson wrote:
>> [...]
>>>>> +    $ENV{PATH} = '/bin:/usr/bin:/usr/local/bin';
>>>>>    my $handle = Symbol::gensym();
>>>>>    open $handle, "$cmd|" or die "$cmd failed: $!";
>>>> What do you need that for and why the hardcoded paths?
>>> That's an artefact from my builds that I could remove, I guess. It's 
>>> because if you run a static build and tests against a non-installed 
>>> httpd
>>> build, the actual httpd binary is a smart libtool shell script plucking
>>> things from .libs/ and such, right? And it uses plenty of ls, sed, 
>>> grep and
>>> friends. When those things are not in the path anymore, the httpd binary
>>> (shell script) will not work at all.
>>> Of course, I don't think there are a lot of folks out there that 
>>> would run
>>> tests that way without installing httpd, but I do.
>> Sure, but the problem is the hardcoded paths, which could quite vary 
>> from machine to machine. I think, instead, one should launder the 
>> original shell's $PATH in this particular case and use it unmodified 
>> (sans making -T happy).
> I agree that hard-coding a path like this isn't quite a good idea.
> But I am not sure what you mean with "sans making -T happy". I can see 
> how one
> could untaint $PATH, but not really how to insure it's clean (except by 
> setting
> it to arbitrary value, like /bin:/usr/bin:/usr/local/bin)

It's a test suite. I fail to see what danger could happen with /(.*)/ 
laundering of $PATH. You can't possibly know what the PATH will be besides the 
common components.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message