Charles Lane wrote:
> The error-throwing suggested was only in response to a system() or
> piped i/o request that couldn't be satisfied because of lacking PERL_ROOT.
Ah OK that is a bit different. In general I am wary of the urge to toss
more warnings into perl. E.g. I think the C<while $scalar=<FILEHANDLE>>
warning in 5.004 was a mistake, despite being very well intentioned.
> But your point is well taken; we may *have* to be able to have a viable
> Perl without PERL_ROOT, ugly though it might be.
>
> And if the test suite shouldn't depend on PERL_ROOT being defined, then
> we should make sure it *isn't* defined (or defined to something non-useful)
> when running the test suite. That's easy enough to do, I'll give it a
> shot.
Most of the time these days I do a configure and build on a box that
already has a previous version of perl that is setup in either sylogin.com
or my processes login.com. This is not to say that there should not
be f$trnlnm("PERL_ROOT") sniffing code in configure.com. Indeed I think
that there should be, although I'd not want to toss it into a call to
bad_environment. Rather the posix Configure script mentions that you seem
to have perl in your $PATH as a type of "warning" that perhaps we should
emulate.
Peter Prymmer
