Chuck Lane wrote:
> A patch for the glob-basic test was posted here on 17 Mar.
Apparently it was missed when assembling 5.6.0 unfortunately.
> The piping changes depend on PERL_ROOT being defined so that the
> DCL wrapper file can be found when spawning subprocesses; in
> discussion with Charles Bailey it was clear that other approaches
> (writing local tempfiles) weren't very secure...and I don't much
> like the idea of "hard-coding" a directory spec into the code.
>
> Is it worth looking for a different method just so we can avoid
> using PERL_ROOT during build/test?
It is my preference that we maintain the insensitivity to PERL_ROOT &&
PERLSHR if possible. If not possible then I can go with putting an @perl_setup
earlier in the descrip.mms although we'd have to take into account the fact
that the PERLSRC tree may differ from the intended PERL_ROOT installation
tree as dictated by the combination of descrip.mms and the installperl script
(in which case putting a DEFINE PERL_ROOT rather than a @perl_setup may be
the better way to go - if necessary).
I am not necessarily opposed to hard coded path names, although I do know
that they can be problematic especially if one has to take into account
the difference between a PERLSRC tree and an installed PERL_ROOT tree.
Would looking at things like $^V help the vmspipe.com situation any? That is
would it help with avoiding collisions with previous, possibly incompatible,
installations of perl (PERL_ROOT, PERLSHR et al.). This is merely a
speculative question on my part as I've not had time to look too closely
at your vmspipe.com stuff just yet.
Peter Prymmer
