in reply to Re: @INC not reflecting correctly
in thread @INC not reflecting correctly

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

Replies are listed 'Best First'.
Re^3: @INC not reflecting correctly
by swl (Prior) on Aug 27, 2021 at 05:20 UTC

    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.

[reply]
      I'm pretty sure this is something that the Strawberry Perl Portable editions work around

      As regards @INC on Windows, there's no need to work around anything as wrt the setting of @INC.
      For example, I have a build of perl-5.30.0 in the location C:/_64/perl530_810.
      It reports @INC as being: 
          C:/_64/perl530_810/site/lib
    C:/_64/perl530_810/lib

      [download]
      I copy that perl to a new location of C:/_64/C/perl530_810.
      Without any need for me to take any additional action at all, this new perl installation correctly reports @INC as being: 
          C:/_64/C/perl530_810/site/lib
    C:/_64/C/perl530_810/lib

      [download]
      This is something that happens automatically on Windows. (I think it just looks at the location of the perl executable and derives @INC accordingly.)
      However, Linux (amazingly) apparently does not provide such a convenience.

      It's not quite so simple for portable Strawberry Perl wrt the correct treatment of %Config settings.
      I think they're probably just rewriting Config.pm and Config_heavy.pl at time of installation.
      (Again, this is a convenience that is unavailable to Linux.)

      Cheers,
      Rob
[reply]
[d/l]
[select]

        Fair point WRT @INC. I still wonder about Config, though.

        The portable version of Strawberry Perl is not installed per se. It just lives in a folder and can be moved around without needing any additional steps to tell Perl where it has been moved to. There are some runtime effects on Config based on the location of the binary, and those are what I cannot locate the source of. Whether those have any bearing on @INC is another question, of course.

        Edit: I think this is answered by haj in 11136120, and is the Portable module.

[reply]
        However, Linux (amazingly) apparently does not provide such a convenience.

        It's not that amazing: in Linux the dir(s) containing the executable(s) is common to all installed programs: /bin, /sbin, /usr/bin, /usr/local/bin. It is not the case that each program has its own private bin/, lib/ (include/, etc/) and keep adding private bin/ dirs to the PATH, which (the PATH) being such a primitive structure it is "difficult" to add a path somewhere in the middle, say, in order to precede some similarly-named program, e.g. another Perl. With a common bin/ dir (Linux), programs have to either overwrite existing one or be renamed. Deriving the INC by and relative to the location of the executable can not work in Linux (5' EDIT: see Re^5: Devel::NYTProf: "undefined symbol: PL_stack_sp" error for how paths are hardcoded within libraries). Or any other sane OS which likes to put its soldiers to a communal camp, provided they all keep clean socks. In this way, a single bin/ file-permissions and other security policy will be saner to maintain. Additionally, there are (usually) no private program installations (re: "Do you wish to install this program for all users or just for you?") except in a groups-based way (e.g. admin, staff, etc.). Again, easier to maintain security policy. The results are obvious from a glance at the battlefield: virtually each and every windows box is pawned (including that windows XP of UK's 3bn nuclear air-carrier, see also here, for the other side of the story).

        bw, bliako

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom