Hello ScarletObsidian, and welcome to the Monastery!

You should have a look at the contents of your PATH environment variable: set path. That should tell you where the older perl is hiding.

However, since you’re using Strawberry Perl, you don’t need to uninstall anything. Just download a “Portable edition” of the perl you want (see http://strawberryperl.com/releases.html), unpack it to a suitable location, and run it via the batch file provided — and, hey presto!, it will just work. (The batch file adjusts the local PATH setting for the terminal it runs in.)

Hope that helps,

Thanks so much for your quick reply! I'll check out the path variable and see if I can't find the ...hidden perl...that's causing me confusion, but portable strawberry perl definitely got me up and running again.

S.O.

/usr/bin/perl is not a standard Windows path, and which is not a standard Windows utility.

Are you using cygwin or similar for the console? If so then the other perl will be somewhere in its directory structure, and should probably be left alone (particularly since you have a working solution using the portable Strawberry perl - 11100238).

That's really strange. Why would "which" work at all if it doesn't come standard. I'm not, to my knowledge, using cygwin or anything like it. I have installed git, github, and various python utilities -- could one of those have brought "which" into the system?

I have installed git, github, and various python utilities ...

Pythonista gits tend to like *nix-ish utilities, so I wouldn't be surprised if one of those installs smuggled the Windows port of the GNU utilities aboard. From my Windows system:

c:\@Work\Perl\monks>which which.exe
c:\UnxUtils\wbin\which.exe
[download]

---

Give a man a fish:  <%-{-{-{-<

Are you using the git-bash console ?

There you'll have which and a Perl installation and Unix paths notation.

That doesn't effect the normal cmd.exe unless you change PATH to point to the git utilities. ( I never tried this)

Anyway perldoc -l MODUL will point you to your Perl's installation directory.

For instance the doc location of a core module like warnings always works.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

update

s/-t/-l/

update

Fired up my Win box and inside cmd.exe it works

D:\>perldoc -l warnings
C:\Perl_524\lib\warnings.pm
[download]

But seems that git-bash comes without perldoc

$ perldoc -l warnings
Can't locate Pod/Perldoc.pm in @INC ...
[download]

But the following works on both variations, provided you swap ' and " accordingly for cmd.exe

$ perl -Mwarnings -e 'print $INC{"warnings.pm"}'
/usr/share/perl5/core_perl/warnings.pm
[download]

D:\>perl -Mwarnings -e "print $INC{q'warnings.pm'}"
C:/Perl_524/lib/warnings.pm
[download]

ANYWAY DON'T TRY TO UNINSTALL git's Perl.

I'm not, to my knowledge, using cygwin or anything like it.

But you do have Cygwin or something like it (maybe msys ?). Nothing else is going to report a path that begins with "/usr/bin".

I have both Cygwin and Msys:

C:\>which which
'which' is not recognized as an internal or external command,
operable program or batch file.

C:\>set PATH=C:\_64\msys64\usr\bin;%PATH%

C:\>which which
/usr/bin/which

C:\>
[download]

and, for Cygwin:

C:\>which which
'which' is not recognized as an internal or external command,
operable program or batch file.

C:\>set PATH=C:\cygwin\bin;%PATH%

C:\>which which
/usr/bin/which

C:\>
[download]

Cheers,
Rob

which which

Perhaps

perl -e "print $^X"
[download]