Charles Lane <[EMAIL PROTECTED]> wrote:
:
: > Charles Lane <[EMAIL PROTECTED]> wrote:
: > | Charles Bailey [EMAIL PROTECTED] wrote:
: > | > Charles Lane <[EMAIL PROTECTED]> wrote:
: > | I'd like to note that if we start using Perl features (@INC, $^X) for
: > | things other than what they were intended, we are asking for trouble.
: > | Just my opinion.
:
: > . . . and a reasonable one, too. I'm not sure we're straying from the
: > intended purpose of @INC, though -- this is a type of library file, in
: > some ways like the (new) dependence of CORE::glob() on File::Glob() (under
: > certain non-VMS OSs) or -d on perldb.pl.
:
: This is just *asking* for a mysterious problem in future. At least
: logicals are automatically available to subprocesses, so they'll have
: the same basic environment as their parent process.
Sounds like a philosophical difference here -- no problem. Perhaps we
could try an intermediate approach:
1. Try ARCHLIB/SITEARCH/VENDORARCH directly.
2. Try dirname($ENV{PERLSHR}) || 'SYS$SHARE:'
3. Fail.
That'll avoid the "user fouls up @INC" concern.
: I'm not sure why we're trying to avoid PERL_ROOT during testing; it's
: a cause of a lot of the grief we're having now. Perhaps it's some
: unix thing, since those poor guys don't have logicals to help them out.
: Sort of like programming without pointers, doncha know :)
Not a bad idea. Perhaps we could acknowledge dependence on it, with
a safety net of
Perl_Root ||= dirname('PerlShr') || dirname($^X) || 'SYS$SHARE:'
in vms_image_init(). That may seem like a bit too much hand-holding;
I'm trying to cover odd installs (there're currently no required
logicals for Perl, assuming you edit the (arch|priv|site)lib config
vars) and embedded interpreters.
: If we go with Dan's suggestion of requiring PERL_ROOT (which I support)
: then the remaining question is "find VMSPIPE using @INC" or "find
: VMSPIPE using something based more directly off PERL_ROOT".
Wups -- maybe I missed something up above. Wasn't the goal here to
avoid searching @INC, given the concern that the user might scramble
it? (If we're going to search @INC, then I'm not sure there's any
advantage to requiring Perl_Root: it's in there unless someone
explicitly removed it, in which case they'd best know what they're
doing.)
: I'm going to have to go looking at the code to see how Perl does it
: before I venture a more considered opinion on the subject. Suggestions
: of where to look will be gladly accepted.
@INC is set up in perl.c (through lots of calls to incpush()); that's where the
brains are. The require-associated lookup is in pp_require() in pp_ctl.c --
it's just iterating over @INC and trying each directory in turn, if the
input filespec isn't absolute. Looks like that'd have to be replicated
in vms.c, since pp_require() goes all the way to the file open.
Regards,
Charles Bailey [EMAIL PROTECTED]
