package My_INC;

BEGIN {
 @INC = qw(
/ajperznes/perl/localperl
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
/ajperznes/perl/lib/site_perl/5.32.0/x86_64-linux
/ajperznes/perl/lib/site_perl/5.32.0
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
          );
};

1;
[download]

C:\>perl -le "print 'PERL5OPT: ' . $ENV{PERL5OPT}; print for @INC;"
PERL5OPT:
C:/perl-5.34.0/site/lib/MSWin32-x64-multi-thread
C:/perl-5.34.0/site/lib
C:/perl-5.34.0/lib/MSWin32-x64-multi-thread
C:/perl-5.34.0/lib

C:\>set PERL5OPT=-MMy_INC

C:\>perl -le "print 'PERL5OPT: ' . $ENV{PERL5OPT}; print for @INC;"
PERL5OPT: -MMy_INC
/ajperznes/perl/localperl
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
/ajperznes/perl/lib/site_perl/5.32.0/x86_64-linux
/ajperznes/perl/lib/site_perl/5.32.0
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0

C:\>
[download]

Then, every time perl is invoked, @INC is set as desired.

Actually, that's not quite always so. This was not what I expected:

C:\>perl -MMath::BigInt -le "print 'PERL5OPT: ' . $ENV{PERL5OPT};print
+ for @INC;
"
PERL5OPT: -MMy_INC
/ajperznes/perl/localperl
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
/ajperznes/perl/lib/site_perl/5.32.0/x86_64-linux
/ajperznes/perl/lib/site_perl/5.32.0
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
[download]

I expected that command to fail because Math::BigInt does not exist in any of those @INC directories that are listed. (It exists only in one of my original @INC directories.)
I expected that command to do the same as the following one-liner (in which PERL5OPT is unset):

C:\>perl -MMy_INC -MMath::BigInt -le "print 'PERL5OPT: ' . $ENV{PERL5O
+PT};print for @INC;"
Can't locate Math/BigInt.pm in @INC (you may need to install the Math:
+:BigInt module) (@INC contains: /ajperznes/perl/localperl /ajperznes/
+perl/lib/5.32.0/x86_64-linux /ajperznes/perl/lib/5.32.0 /ajperznes/pe
+rl/lib/site_perl/5.32.0/x86_64-linux /ajperznes/perl/lib/site_perl/5.
+32.0 /ajperznes/perl/lib/5.32.0/x86_64-linux /ajperznes/perl/lib/5.32
+.0).
BEGIN failed--compilation aborted.
[download]

But instead it processed the -MMath::BigInt before it processed the -MMy_INC. That is, it does the same as:

C:\>perl -MMath::BigInt -MMy_INC -le "print 'PERL5OPT: ' . $ENV{PERL5O
+PT};print
for @INC;"
PERL5OPT:
/ajperznes/perl/localperl
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
/ajperznes/perl/lib/site_perl/5.32.0/x86_64-linux
/ajperznes/perl/lib/site_perl/5.32.0
/ajperznes/perl/lib/5.32.0/x86_64-linux
/ajperznes/perl/lib/5.32.0
[download]

Is it possible to have perl process the contents of PERL5OPT *before* any -M... command line switches are processed ?

UPDATE: I don't think this would be an issue for dirtdog because, IIUC, the directories in his original @INC don't exist anyway.

Cheers,
Rob

I'm pretty sure this is something that the Strawberry Perl Portable editions work around. I seem to remember there is some modification of Config.pm or one of its associated files to use local values. I just can't find the mechanism at the moment.

So, it seems like you haven't actually installed Perl, you have unpacked a tar from another server. This explains the behavior.

The initial list of directories in @INC is created when Perl is built, from data given to the Configure script. They end up "compiled into" the binary (a shared library for most distributions). So, unless the initial installation took care, there's no easy way to copy an installation around.

You can fiddle with @INC at runtime as suggested by syphilis but as you see, this looks like a bit of guesswork. Is there any reason why you can't just install Perl on the target server?

If you build your own Perl, you can use the configure option userelocatableinc (see Config) to get a Perl where @INC is created at runtime from the location of the binary. BTW: This is not how Strawberry Perl does it. Strawberry's portable editions are using Portable to do the trick, but as syphilis has noticed, you can copy the "non-portable" Strawberry editions on Windows just as well (I haven't figured out how this is done).

win32_get_sitelib

... you may want to experiment with sitecustomize.pl

from the docs:

> The code is executed very early. For example, any changes made to @INC will show up in the output of `perl -V`

I can't easily reproduce your problem and there is certainly a timing issue about when @INC is populated, so no guaranty whatsoever.

HTH! :)

Portable

or relocatable inc

Re^7: Why does PERL5LIB need to be so verbose? (installstyle sitelib installlib vendorlib INST_ARCH INST_VER userelocatableinc @INC)

Re^3: Why does PERL5LIB need to be so verbose? ( shebang )

As has been noted previously, by default Perl is not relocatable. A non-relocatable Perl can be moved, but only to a new directory structure identical to the one it came from.

However, if you are using an OS that supports symbolic links and you create symbolic links that mimic the old directory structure, you can fool Perl. This worked for me under macOS after an upgrade decided the Perl I had installed in the file system root wasn't allowed to be there, and willy-nilly moved it someplace else. I was able to get a symbolic link created to the new location, and Perl was happy.