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 http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
