Cannot pass command line arguments in Vista

Posted by gminnick on 2007-07-20 06:46

I have a situation where the command line arguements will not get passed to my perl script in Vista.

Here is a simple script

# script
print $ARGV[0];

In Vista, if I type hello

I get nothing. This does work in XP

However, if I type

perl Hello

I get "Hello" as the output.

After searching other forums on the internet I think this has something to do with how perl is associated in Vista and the file type.

I found this bit of information that relates to my problem, even though it is for Python.

It sounds like the registry entry for running Python files is messed up.
Can you go to a command line and see what the command 'ftype Python.File'
displays? (Assuming that command lines and ftype still work on Vista)

The output should be:
Python.File="C:\Python25\python.exe" "%1" %*

but if it only says:
Python.File="C:\Python25\python.exe" "%1"

then you would get the behaviour you observed (on any version of Windows,
not just Vista).

I cannot find the Perl filetype to run the ftype command. I don't know enough about the Windows registry and file type associations to figure this out. The .pl ext is associated in Default Programs under Control Panel.

Any help would be appreciated.

ddn123456 | Mon, 2007-07-23 23:39

The perl ftype filetypes are documented as the following:


With kind regards.

gminnick | Tue, 2007-07-24 04:51

I checked and those do now show up when using ftype. Can you tell me what they should be along with the assoc command for each ftype?


ActiveState Staff
Fri, 2007-09-28 15:27

I see this back from ftype on WinXP:
Perl="C:\Perl\bin\perl.exe" "%1" %*

pmartel60 | Sun, 2011-07-24 17:08

I'm updating this old thread to leave this trail marker, as I might not be the last poor searcher that Google sends here.

I just had the same problem of missing arguments to perl scripts on the Vista command line, and found a way out.

The problem was NOT in the file's type association as reported by assoc (for .pl) and ftype (for Perl).

The problem only went away when I used regedit to delete registry entry at:

This re-enabled the default behavior described by assoc and ftype, namely that a .pl file is a Perl file and that Perl files are launched with "C:\Perl\bin\perl.exe" "%1" %*
where %1 is the path to the .pl file and %* means "passing all the other command line arguments".

Longer story:

These ...\FileExts\... entries seem to get populated via Windows Explorer commands like Open, Open With..., and Properties|Open With:Change.
Normally, the entry at ...\FileExts\.pl mimics the "assoc" entry at:

and that, it seems, is how/why Windows Explorer defines "Open" (or double-click, etc.) to mean "launch a perl script with no arguments". OK. Mostly harmless.

But I wanted "double-click" to Open the script for editing, not execution.
So I used Windows Explorer's "Open With | Change Default Program..." to redefine "Open" to launch an editor window with the .pl file.

This had the intended effect on double-click and it changed the ...\FileExts\.pl entry but did NOT change the entries reported by assoc for .pl or ftype for Perl.
And that would be GREAT except it DID change the behavior of executing a .pl file on the command line.
It now launched the editor instead of the script, regardless of what assoc and ftype were reporting.

OK. My bad. So I used "Open With | Change Default Program..." again to try and "undo" the damage. I selected the perl command line interpreter as the program to Open .pl files.
It was highlighted as the default option, so that was easy enough.

Now .pl files on the command line were executing again, BUT they were ignoring any command line arguments, until I used regedit to delete the entry mentioned above.

I had to stop along the way to get permission to delete the entry, but that's another story.

Windows Explorer eventually restored the entry to its mostly harmless value, probably the next time I double-clicked a .pl file.

In experiments with Windows Explorer on my own file extensions and dummy "scripting" executables (batch files that echo their command lines) I've SOMETIMES been successful at restoring command line argument passing by operating within Windows Explorer and sometimes not.
But the "regedit" technique always worked for me and was the the only thing that seemed to work for restoring command line args specifically to the perl command line interpreter.
I don't know why. Your mileage may vary.

lumsama | Fri, 2018-07-06 03:17

Having the same issue in WIN 10

ActiveState Staff
Fri, 2018-07-06 10:59

The original script is too simple.

.pl script files MUST have a shebang line if you want to invoke them without calling Perl first.

There is a little known foible of the Windows port for Perl.

While the shebang line works as advertised on *nix and BSD, Windows can't really support it as intended. Instead, the shebang line is scanned for *any* occurance of "perl". It does not matter if the path in the shebang line actually exists as long as the word "perl" can be found somewhere in the shebang line.

The problem with the original script is that without the shebang line, perl is not called automatically.

Adding a shebang line to your script should fix your issue on any version of Windows.