All of a sudden, perl scripts don't work unless I prefix them with "perl" and give full path to the script

Question

I've been using my own personal environment that's worked consistently for over 20 years. I started incorporating many perl scripts about 14 years ago. I've been using the same tree of command-line interpreters for 22 yrs (NDOS->4DOS->4NT->TCMD, all the same program really).

I just switched from ActiveState windows perl to Strawberry Perl.

For years, this is all I've needed to run a perl script:

SET .pl=perl

This is how you specify what program to open things with.

this I can simply do:

c:\>test.pl
Hello, world!

Things just worked. Forever.

Today, in a week-old OS, things just stopped working.

Perl scripts will run, but they won't DO anything. No error. No output. Nothing.

The only way it works is if I prefix the script with "perl" (in which case, my path isn't searched because script name is now a parameter, so I'm left having to fill in the full path for the script)

Here's what it's like to be me:

C:\>test.pl

C:\>perl test.pl 
Can't open perl script "test.pl": No such file or directory

C:\>perl c:\bat\test.pl 
Hello, world!

Note that this was working fine yesterday, even earlier today. I don't know what changed this and what broke it, and I've looked quite a long time, found similar but not identical issues - and no fix has helped.

I hvae a boatload of scripts. I would really hate to have to insert the world "perl" before every one of them, and then qualify the full path!

Realistically, I will probably have to write a perl.bat wrapper that converts the parameter filename into a fully qualified path, and explicitly calls perl.

I really don't want to do that. That's a ban-aid solution. I want to understand what is wrong, address is, and resolve it.

I'm starting to hate Windows 7...

Paronomasia

Answer 1

I think your problem is most likely that association to .pl to perl.exe is broken.

Look at HKEY_CLASSES_ROOT\.pl in registry it probably has Perl(or say FOO) subnode under it

Now look at HKEY_CLASSES_ROOT\Perl or FOO if that is the case.

It should have a shell\Open\command key

which should look something like this

  "C:\Perl\bin\perl.exe" "%1" %*

Of course the perl.exe path on your system might be different. The %* is the important bit which passes the arguments that you pass to your script to perl.exe

So when you do "test.pl foo bar" in a command window, the shell behind the scenes is actually invoking

C:\perlpath\perl.exe C:\scriptpath\test.pl foo bar.

This sort of problem happens when you simply pick a *.pl file in the windows explorer and try to associate it with perl.exe.

As a added bonus, If you add .PL to PATHEXT enviroment variable you even don't have to specify test.pl simply test will invoke test.pl if it is first in the path :)

Blakeney

I think a command line to check your file associations is via the "assoc" command. Typing assoc .pl on my Windows machine produces ".pl=", which means my .pl files aren't associated with Perl. Good luck! – Sulfamerazine

Answer 2

Windows Powershell

In Windows Powershell, add .PL to the PATHEXT environment variable (otherwise the script will run in a separate CMD window).

However, Powershell will not run commands unless they are in PATH (i.e. "." is not in $env:PATH by default, a bit like root on Unix)

So, to run a script

./script 
./script.pl

Easiest way is to use the Powershell profile.

e.g. in C:\Users\username\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

$env:PATH   = "C:\strawberry\perl\bin;$env:PATH"
$env:PATHEXT    = "$env:PATHEXT;.PL"

If you want to not have to do ./ (and note, this is a security risk), add "." to the path (without the quotes)

$env:PATH   = "C:\strawberry\perl\bin;$env:PATH;."

Then you can just do

script

Leventhal

Answer 3

You can check your file extension association by right clicking a .pl file, select properties, and click the "open with" button (this is XP, I don't know how it looks in Windows 7). It may be that your extension is pointing to the wrong place.

Velez