in reply to Cleaning %PATH% with WinBatch

Hello LanX,

> To make this even more idiot proof .. I'd like to purge all older entries from PATH

I dont see the point: if you prepend your desired perl to PATH (as portableshell.bat does) there is almost no risk of collision: only a call to a make flavour not present in the first distribution can lead to problems. I mean: if you cast perl5.34 and this does not contains nmake (just as example) but this executable is present in perl5.10 just few entry onward in PATH ..so this can be a problem. It seems to me a very advanced usage so probably not your (collegues) case.

If you are already using portableshell.bat you can simply hardcode your desired PATH modifying the line..

set PATH=%~dp0perl\site\bin;%~dp0perl\bin;%~dp0c\bin;%PATH% # ...to something like set PATH=%~dp0perl\site\bin;%~dp0perl\bin;%~dp0c\bin;c:\Windows;C: +\Windows\System32;

The above is generally enough.

In more customized scenarios you can reuse other ENV entries to build up your final PATH for example:

HOMEDRIVE=C: ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files windir=C:\WINDOWS

PS more on this:

> off course I could spawn a perl one-liner, but the basic idea of BAT is to keep the delay minimal

Perl is already here and used, so if you prefere perl over batch (;) you can use it to change $ENV{PATH} you only need to modify the perl oneliner aimed to print nice stuff on screen:

# line 24 of portableshell.bat perl -MConfig -e "printf("""Perl executable: %%s\nPerl version : %%v +d / $Config{archname}\n\n""", $^X, $^V)" 2>nul

I hope File::Spec can handle weird windows names correctly using path separtor and the idiom @PATH = File::Spec->path();

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Replies are listed 'Best First'.
Re^2: Cleaning %PATH% with WinBatch
by LanX (Saint) on May 23, 2022 at 08:34 UTC
    > I dont see the point: if you prepend your desired perl to PATH (as portableshell.bat does) there is almost no risk of collision: only a call to a make flavour not present in the first distribution can lead to problems.

    I disagree, I had a case where AS and SB where both installed via MSI and the installations confused each other.

    • perldoc was confused
    • cpanm had mysterious fails
    I haven't tested yet but I suppose two portable SBs in the path will lead to the primary searching for modules in the secondary (there is no PERL5LIB (possible typo?) setting, they are dynamically derived from the path)

    I prefer operation with a clean slate...

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      Hello again LanX,

      > I suppose two portable SBs in the path will lead to the primary searching for modules in the secondary

      It is very disappointing but you are right (not for you, for the fact itself ;)

      perl -v This is perl 5, version 26, subversion 0 (v5.26.0) built for MSWin32-x +64-multi-thread # this perl has MCE support perl -MMCE -e 1 # and this is its path PATH=C:\EX_D\ulisseDUE\perl5.26.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\c\bin; C:\EX_D\ulisseDUE\bin\UnxUtils\usr\local\wbin; C:\WINDOWS; C:\WINDOWS\system32; # this other one is 5.20.3 WITHOUT MCE perl -v This is perl 5, version 20, subversion 3 (v5.20.3) built for MSWin32-x +64-multi-thread # original path PATH=C:\EX_D\ulisseDUE\perl5.20.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\c\bin; C:\EX_D\ulisseDUE\bin\UnxUtils\usr\local\wbin; C:\WINDOWS;C:\WINDOWS\system32; perl -MMCE -e 1 Can't locate MCE.pm in @INC (you may need to install the MCE module) (@INC contains: C:/EX_D/ulisseDUE/perl5.20.64bit/perl/site/lib C:/EX_D +/ulisseDUE/perl5.20.64bit/perl/vendor/lib C:/EX_D/ulisseDUE/perl5.20. +64bit/perl/lib .). BEGIN failed--compilation aborted. # prepending the other version in PATH set PATH=C:\EX_D\ulisseDUE\perl5.26.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\c\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\c\bin; C:\EX_D\ulisseDUE\bin\UnxUtils\usr\local\wbin; C:\WINDOWS; C:\WINDOWS\system32; path PATH=C:\EX_D\ulisseDUE\perl5.26.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\c\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\c\bin; C:\EX_D\ulisseDUE\bin\UnxUtils\usr\local\wbin; C:\WINDOWS; C:\WINDOWS\system32; # now... omg UPDATE: wrong assumption from my part: see below Anonymou +s Monk at 11144117 perl -MMCE -e "print $INC{'MCE.pm'}" C:/EX_D/ulisseDUE/perl5.26.64bit/perl/site/lib/MCE.pm

      The wonderful cpanm program is problematic on windows: Re: Should cpanminus be part of the standard Perl release? -- MSWin32

      I'd hardcode PATH inside the portableshell.bat

      PS

      if the alien perl is appended to PATH the beahviour is sane

      set PATH=C:\EX_D\ulisseDUE\perl5.20.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.20.64bit\c\bin; C:\EX_D\ulisseDUE\bin\UnxUtils\usr\local\wbin; C:\WINDOWS;C:\WINDOWS\system32; C:\EX_D\ulisseDUE\perl5.26.64bit\perl\site\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\perl\bin; C:\EX_D\ulisseDUE\perl5.26.64bit\c\bin; perl -MMCE -e "print $INC{'MCE.pm'}; print @INC" Can't locate MCE.pm in @INC (you may need to install the MCE module) ( +@INC contains: C:/EX_D/ulisseDUE/perl5.20.64bit/perl/site/lib C:/EX_D +/ulisseDUE/perl5.20.64bit/perl/vendor/lib C:/EX_D/ulisseDUE/perl5.20. +64bit/perl/lib .). BEGIN failed--compilation aborted. which perldoc.bat C:\EX_D\ulisseDUE\perl5.20.64bit\perl\bin\perldoc.bat

      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

        Hello again LanX, > I suppose two portable SBs in the path will lead to the primary searching for modules in the secondary It is very disappointing but you are right (not for you, for the fact itself ;)

        whatwhat you posted shows that doesnt happen , perl doesnt search %path% for more @inc entries

      Funny conclusion. None "set perllib". Only issue would be ftype/assoc clobbering and Pl2bat still like an idiot still relies on %path%
        hmm ... this looks promising ... but only shows it working for a pure set of portable SBs

        C:\tmp>%PERL_532% /SETENV C:\tmp>where perl c:\nonBKU\strawberry-perl-5.32.1.1-64bit-portable\perl\bin\perl.exe C:\tmp>perl -v This is perl 5, version 32, subversion 1 (v5.32.1) built for MSWin32-x +64-multi-thread ... C:\tmp>perl -MData::Dump -E"dd \%ENV" { ... "PERL" => "C:\\Perl_524\\bin\\perl5.24.1. +exe", "PERL_524" => "C:\\Perl_524\\bin\\perl5.24.1. +exe", "PERL_530" => "C:\\nonBKU\\strawberry-perl-5. +30.3.1-64bit-portable\\portableshell.bat", "PERL_532" => "c:\\nonBKU\\strawberry-perl-5. +32.1.1-64bit-portable\\portableshell.bat ", ... } C:\tmp>perl -MData::Dump -E"dd \@INC" [ "c:/nonBKU/strawberry-perl-5.32.1.1-64bit-portable/perl/site/lib/MSW +in32-x64-multi-thread", "c:/nonBKU/strawberry-perl-5.32.1.1-64bit-portable/perl/site/lib", "c:/nonBKU/strawberry-perl-5.32.1.1-64bit-portable/perl/vendor/lib", "c:/nonBKU/strawberry-perl-5.32.1.1-64bit-portable/perl/lib", ] C:\tmp>%PERL_530% /SETENV C:\tmp>perl -v This is perl 5, version 30, subversion 3 (v5.30.3) built for MSWin32-x +64-multi-thread ... C:\tmp>perl -MData::Dump -E"dd \@INC" [ "C:/nonBKU/strawberry-perl-5.30.3.1-64bit-portable/perl/site/lib", "C:/nonBKU/strawberry-perl-5.30.3.1-64bit-portable/perl/vendor/lib", "C:/nonBKU/strawberry-perl-5.30.3.1-64bit-portable/perl/lib", ] C:\tmp>

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery