Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 11:17 AM 4/3/00 -0400, Charles Lane wrote:
>> > How 'bout doing a regular @INC lookup, and installing vmspipe.com in
>> > the library?
>>
>>Hmmm....that's got a ton of implications, you know.
>>
>>For example, a user's script mucks around with @INC and then can't do
>>any system() calls. Not exactly an "obvious consequence".
>
> That'd be profoundly bad, I think. Hardcoding PERL_ROOT:[LIB] (or wherever
> it goes by default) as a final default might not be unreasonable.
Well, as far as I can tell the *only* place having VMSPIPE.COM in
PERL_ROOT:[000000] could *maybe* be an issue is during the Perl
build/test/install.
But that all occurs in what (should be) a rather well controlled
environment. As has been mentioned, MMK and MMS do their stuff in
a subprocess...we can set a process logical to make the build/test/install
work okay without mucking about with the main process logicals.
(this may also be a good thing for dealing with "dangerous
logicals/symbols" that we currently just check for in CONFIGURE.COM:
delete 'em all except for the ones we need)
Depending on @INC to find VMSPIPE, whatever the "last chance
defaults", means that when running perl in an *uncontrolled*
environment (i.e, Joe User running a script) we'll be vulnerable to
odd behavior with the system() function and piped i/o (ex: a user's
@INC points to his local directory with a VMSPIPE.COM that does
something different, or can't be read because of protections).
....
and when you do a "subprocess of a subprocess" (like during some of
the tests) and you *don't* have PERL_ROOT defined, do you *always*
pass the correct "-I..." flag? Even when it's for a subprocess that
doesn't use modules?
How about this as an alternative for finding VMSPIPE.COM:
translate logical PERL_VMSPIPE_DURING_MAKE in LNM$PROCESS,
and if present, use it.
else look for a readable PERL_ROOT:[000000]VMSPIPE.COM, if found use it.
...otherwise, just fail with a suitable message.
You still set a logical during build/test/install, but it doesn't have
to be PERL_ROOT.
You test for PERL_VMSPIPE_DURING_MAKE first, since there may be a
(LNM$GROUP/LNM$SYSTEM) old PERL_ROOT hanging around. It has to be in
LNM$PROCESS so that you're sure it's really from "the current MMK
run", rather than some weird leftover in some another table. And it
would be inherited by "subprocesses of subprocesses".
>>I'll have to do some poking to see whether a @INC scheme would work
>>for miniperl during the build...since miniperl can't do "use" but
>>does do "system()", it's not clear that @INC is set up properly.
>
> miniperl *can* do a use. It can do anything that perl can except use XS
> modules. Regular .PM-only ones work just dandy. (The build of perl itself
> couldn't succeed if that weren't the case)
My mistake...I recall doing a "use ..." in miniperl and having it bomb
on me; it must have been a module with XS code.
--
Drexel University \V --Chuck Lane
----------------->--------*------------<[EMAIL PROTECTED]
(215) 895-1545 / \ Particle Physics [EMAIL PROTECTED]
FAX: (215) 895-5934 /~~~~~~~~~~~ [EMAIL PROTECTED]
