How do I make Perl scripts recognize parameters in the Win32 cmd console?

Question

When I invoke my Perl scripts in the Windows environment without invoking perl first, the parameters are not passed to my script.

For example,

C:\> C:\my-perl-scripts\foo.pl bar

invokes foo.pl but doesn't recognize bar as a parameter (@ARGV is empty). However,

C:\> perl C:\my-perl-scripts\foo.pl bar

works as expected.

Is this a configuration issue?

Ideally, I'd like to be able to distribute some perl scripts, have the user add C:\my-perl-scripts\ to the path and then just be able to invoke foo.pl from anywhere while running cmd.

If they have to specify perl first, then they'll always have to give a complete path.

Any ideas or recommendations?

Edit: To show that the assoc and ftype are correct on my system, I executed the following commands.

C:\>assoc .pl
.pl=Perl

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

C:\>more t.pl
print "'$_'\n" for @ARGV;

C:\>t a b

C:\>perl t.pl a b
'a'
'b'

C:\>t.pl a b

C:\>

I included both the output of t and t.pl to show it's not a %PATHEXT% problem. Both outputted nothing as originally described whereas invoking perl first gave the expected response.

I'm not sure where to look next, but thanks for the suggestions so far. They have been very helpful.

Edit 2: The problem appears to be on my vista business box. On my xp pro box, it works as expected. Both have ActivePerl 5.8.9. I have another vista home box that I have not yet tried yet. I'll post back if I discover anything.

Edit 3: I found the answer (posted below). I found it by running a registry cleaner, removing perl, running the registry cleaner again. On 2nd cleaning, only one invalid entry remained - the one that was causing the problem (probably left over from a previous installation).

Answer 1

Hmmm... sounds like the file association for *.pl is messed up somehow. I'm not on a Windows box, so I can't test this. You can check the file association stuff with either the ASSOC or FTYPE command on the command-line. IIRC, "ASSOC .pl" should tell you what the file type is and "FTYPE filetype command" tells the shell what to do with a Perl script. Try something like:

C:\> ASSOC .pl=perlscript
C:\> FTYPE perlscript=C:\Perl\bin\perl.exe %1 %*

From the looks of one of the command references that should do the trick. My guess is that the current association is not passing the parameters along to the script. You should be able to check that by using ASSOC .pl to figure out what the name of the file association is and then using FTYPE to print out the command that the shell is going to execute.

Update

I found an interesting thing that I want to note for posterity. I started seeing exactly this problem on a friends machine at work with respect to some Python scripts. ASSOC and FTYPE resulted in the expected output but the parameters were still not being passed along - exactly what was originally reported.

After a little digging, I found that the registry settings were created somewhere along the line as REG_SZ values. I deleted them and re-created them using ASSOC and FTYPE and everything started working... looking at the registry gave me the answer the new values were created as REG_EXPAND_SZ! These worked exactly as expected.

Answer 2

Update: Given that the following is correct, the only thing left to make sure is that command extensions are not turned off. Try:

cmd /e:on

on the command line before you run your tests. See also Windows XP cmd documentation:

Enabling and disabling command extensions

Command extensions are enabled by default in Windows XP. You can disable them for a particular process by using /e:off. You can enable or disable extensions for all cmd command-line options on a computer or user session by setting the following REG_DWORD values:

HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD

HKEY_CURRENT_USER\Software\Microsoft\Command Processor\EnableExtensions\REG_DWORD

Set the REG_DWORD value to either 0x1 (that is, enabled) or 0x0 (that is, disabled) in the registry by using Regedit.exe. User-specified settings take precedence over computer settings, and command-line options take precedence over registry settings.

E:\Temp> assoc .pl
.pl=Perl

E:\Temp> ftype Perl
Perl="C:\opt\Perl\bin\perl.exe" "%1" %*

E:\Temp> @echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PL;.PLX;.WPL;.py;.pyw

E:\Temp> cat t.pl
print "'$_'\n" for @ARGV;

E:\Temp> t a b c d e f g h j
'a'
'b'
'c'
'd'
'e'
'f'
'g'
'h'
'j'

I have used pretty much every ActiveState Perl distribution since 2004. These settings are enough to make it work.

Answer 3

I found out what the problem was. Although the ftype and the assoc values were set as suggested, the actual behavior on my system seems to be determined by the registry key

HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command

It should have a (Default) string value of "C:\Perl\bin\perl.exe" "%1" %*

When I found this entry, it was set to "C:\Perl\bin\perl.exe" "%1". Changing it immediately fixed the problem.

Why it was set that way in the first place? I don't know. Maybe from a previous installation?

Anyway, thanks for the suggestions, and I hope this answer helps someone else, too.