The perl you are running is not Strawberry Perl:

This is perl, v5.6.1 built for MSWin32-x86-multi-thread
...
Binary build 631 provided by ActiveState Tool Corp. http://www.ActiveS
+tate.com
[download]

Most likely there is no C:\Strawberry\perl\bin or it is not readable for the user you are using.

Try launching Strawberry Perl explicitly:

C:\Strawberry\perl\bin\perl.exe -v
[download]

Thanks for the quick reply! I dit it again after a reboot:

PS C:\Users\***> C:\Strawberry\perl\bin\perl.exe -v
This is perl 5, version 30, subversion 0 (v5.30.0) built for MSWin32-x
+64-multi-thread
Copyright 1987-2019, Larry Wall
[download]

Built 17:16:22 Jan 2 2002

I'd look where it is located, and, more importantly, where / by whom or what it is used. There have been significant enhancements since 5.6.1, so it might be worth the hassle to lift that user to a newer version.

Hum, that's not solved for me :s. He gave me the good version manually, but sill not ok when i just do "perl -v". Strange too, i just install the last version of Strawberry Perl, do you know why the system still see this old version? In "Programs and Features" i only have Strawberry. i'm sorry, but i'm a totally newbie on Perl! ...

Think of it this way: You have two versions of dosomething.exe installed; One lists files, and one prints hello world. You put the lists-files one in your path so that you can type "dosomething" and a file listing occurs. To get to the hello-world version, you have to use its fully-qualified name; the absolute path, because there are two different executables on your system by the same name. If you were to update your path to find the hello-world version of dosomething.exe first, it would win when you type the command name, and you would then have to type the full path to reach the list-files version of dosomething.exe

You have two executables on your system that both are named perl.exe. One of them is a 2002 version of Active State Perl. One is a newer version of Strawberry Perl. They reside at different places on your filesystem, and their libraries live at different places. They usually can co-exist but it's possible the old ActiveState install is broken. But your question really relates to how to make Strawberry Perl's perl.exe get priority in your PATH. That would be the same question whether we're talking about perl.exe or dosomething.exe.




Dave

Both Strawberry and ActiveState behave pretty well according to Win32 path and install standards. Whether the previous admin of this box kept to those standards, might be another story. Managing environment variables on Windows Server 2012 is more of a Windows Server admin question than a Perl question. That being said, it's pretty easy: Control Panel > System and Security > System > Advanced System Settings, and then look for the Environment Variables button (might be in a different tab), or ask your network admin for assistance.

As Corion already noted, perl runs ActiveState Perl instead of Strawberry on that system. It's a minor red flag (pinkish flag?) for me that 5.6.1 was already at least ten years old when that server was deployed, so I'd take a careful look for any legacy Perl code on that system, to make sure nothing breaks. If you install Strawberry for a single user (rather than system-wide), it's relatively safe, unless of course that user is the one the scripts run as. Then you can fix the paths for Strawberry Perl.

If you run C:\Strawberry\perl\bin\perl.exe -eprint@INC, do you get a more reasonable list? If so, the @INC problem will hopefully stay with the ActiveState install. But if not, it may be a system config issue. In that case, I'd start with an envdump a look at your environment variables to see if any PERL* environment variables have been set, such as PERL5LIB, and if they are, track down where they're being set on your system.

If you're confident you've identified all Perl code on the system (if any), and confirmed it'll run on the latest Strawberry Perl, you can probably get rid of the AS Perl install. It's normally fine to have them both installed, as long as you manage your paths properly, but if it's a broken (and ancient) install anyway, you may be better off without it.

Thanks for your answer. Hum, don't remember how Strawberry was install, not sure for the single user. I really don't know how to fix that path or anything else, i feel like in a huge ocean without a buoy! ^^ Here's the result of the commande C:\Strawberry\perl\bin\perl.exe -eprint@INC

PS C:\Users\*****> C:\Strawberry\perl\bin\perl.exe -eprint@INC
C:/Strawberry/perl/site/libC:/Strawberry/perl/vendor/libC:/Strawberry/
+perl/libPS
[download]

I have to find how to launch an envdump to see if any PERL* environment variables have been set. All scripts are OK, i test them on the last strawberry version on my own computer.

Sorry for the confusion on "envdump". That just means "environment dump," but more generally, simply having a look at the environment variables on your system, which I explained how to do in this other reply in this question thread.

However, the results of your print @INC seem fine, so once you get your paths sorted out so C:\Strawberry\perl\bin comes before ActiveState's directory in your PATH, you'll be running Strawberry Perl whenever you simply run perl, without the need for the fully qualified path.