Charles Lane wrote:
> Charles Bailey [EMAIL PROTECTED] wrote:
> > What would you think of this alternative?
>
> > 1. Search @INC for file.
> > 2. On failure, try dirname($^X).
> > 3. Perhaps as last resort, try Perl_Root:[000000], though I'm
> > not sure this'll add much.
> > 4. Do the lookup from init_os_extras() (after -I and PERL5LIB
> > processing, but before the Perl code has a chance to fuss
> > with @INC or $^X.
>
> > Putative advantages: Incorporates normal Perl library mechanisms for
> > adapting to multiple versions/architecures, and provides a relatively
> > clean way to redirect. Putative disadvantages: Possible security concern
> > with -I, but if you allow users to specify -I when invoking sensitive scripts,
> > you may have a bigger problems (though script can say C<@INC = qw( ... )>);
> > possible inadvertent breakage through existence of an unrelated vmspipe.com
> > in -Id directory, as with any Perl library file.
>
> 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.
I might argue that @INC is actually for the sort of thing your trying to
do with vmspipe.com. Namely that perl.exe needs to find a file that is
a part of it's "library". Of course DCL is not a .pm perl module.
But there is precedent for shell scripts that perl depends on elsewhere.
As an example consider those unix ports of perl that need to toss a lot
of extra arguments in front of their C compiler before it can be called
a C preprocessor suitable for perl's -P switch and distinct from the
cpp invokation used to ascertain perl .c && .h file dependencies. This
gets put into a $Config{'cppstdin'} variable that is invoked as necessary
during `make test` and also installed as part of `make install`.
An illustration of this is the OS/390 port where after I've typed `make
install` for perl look what pops into my $prefix/bin directory:
$ cat /usr/local/bin/cppstdin
cat >.$$.c; c89 -E -Wc,NOLOC ${1+"$@"} .$$.c; rm .$$.c
> 1. Perl installed, normal "user" execution:
> Since the search is in compiled code, why not just use ARCHLIB?
> Then we're not affected by -I and we still get architecure/versioning.
> This should work fine for an installed Perl.
>
> If we really need to search @INC, I'd say that we should do
> something like reverse the order of directories, drop the '.'
> directory and prepend an ARCHLIB. That way any -I directories are
> at the end of the list, and ARCHLIB (where VMSPIPE almost certainly is
> located) gets checked first.
>
> And rather than having the performance hit of searching the directories
> each time Perl is run, it would be better just to cache a list of
> directories and search in the safe_popen routine.
>
> 2. during MMK (build phase):
> assume PERL_ROOT "not useful" (not defined, old version)
> @INC search will fail, but
> dirname($^X) should work fine.
>
> 3. during MMK TEST:
> assume PERL_ROOT "not useful".
>
> So all the directories in @INC that are based on PERL_ROOT are
> unusable for finding VMSPIPE.
>
> During MMK TEST, we copy PERL.EXE to [.T]PERL., so dirname($^X)
> won't help us much unless we also copy VMSPIPE.COM to [.T]
> (with unknown effect on test scripts that use that directory
> as part of their testing schemes).
>
> As I mentioned in a previous message, I don't think we can count
> on test scripts that spawn subprocesses passing an appropriate
> -I flag to subprocesses that aren't using modules...and the -I
> directories won't be the ARCHLIB directory that we really need.
>
> Which leaves us with what? No @INC (no PERL_ROOT, no -I)
> No $^X (since in [.t])
> No PERL_ROOT
>
> This area remains a problem.
Nah. Just put in a dependency on [.t]vmspipe.com and a rule to copy it.
No problem.
> 4. During MMK INSTALL:
> PERL_ROOT is set to installation location
> we may or may not have VMSPIPE findable via @INC, depending on
> when VMSPIPE is copied to its new location.
> $^X should still work though.
Copying vmspipe.com over to the new PERL_ROOT is a vms specific thing
and we may not want to code it into the installperl script and could put
a simple:
@ copy/log vmspipe.com perl_root:[000000]
into descrip.mms before invoking installperl. This ought not be too much
of a problem.
Peter Prymmer
