> At 10:29 AM 4/3/00 -0700, [EMAIL PROTECTED] wrote:
> >Dan Sugalski wrote:
>> > couldn't succeed if that weren't the case)
> >
> >I think a hardcoded PERL_ROOT:[LIB] or an @INC lookup (though I'm not
> >sure about @INC since miniperl does use it) runs into trouble with the
> >"need" to have PERL_ROOT DEFINEed. Would looking at the $^X file path
> >help with a PERL_ROOT-less environment?
> Might, I suppose. We could use $^X to build perl_root on the fly.
> At this point I'm thinking we might as well officially make perl_root
> mandatory. We haven't been able to live without it for ages (if ever) and
> it's the one thing that makes install on an ODS-2 reasonably flexible, so...
While my first reaction to using $^X is "great!" I just recalled the
number of times recently that I had scripts with:
$^X = 'miniperl';
open(S,"$^X ...|") ;
...
The reason? Well, I'm running the main script in dbgminiperl, and I don't
want subprocesses to start the debugger. When things are debugged,
the $^X line is commented out. Both "miniperl" and "dbgminiperl"
were defined as symbols, but there's no reason I couldn't set
$^X to "show logical/process" for debugging purposes.
In my mind, the difficulty with @INC, $^X and other "internal to Perl"
methods is that they too easily run afoul of users messing about or even
doing sensible things, and generating unexpected side-effects.
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
