Please post the output from running the following commands in a cmd.exe shell:

C:\D\test>assoc .pl
.pl=Perl

C:\D\test>ftype Perl
Perl="c:\perl64\bin\perl.exe" "%1" %*

C:\D\test>set pathext
PATHEXT=.pl;.COM;.EXE;.BAT;.CMD;
[download]

The first 2 commands give the identical results as your example.

the final one, 'set pathext' shows a lot of file extensions, but NOT .pl! Even though the assoc command appeared to run without error.

My problem is not that the system doesn't execute perl. It finds and executes perl, but doesn't pass the command line parameters to @ARGV.

The first 2 commands give the identical results as your example.

You sure?

The only thing I am aware of that could be affecting this, is if the ftype were set wrong. For example, if the ftype were set as:

Perl="c:\perl64\bin\perl.exe" "%1"
[download]

That would disable the passing of arguments:

C:\test>type argtest.pl
#! perl -slw
use strict;

print for @ARGV;


C:\test>ftype Perl
Perl="c:\perl64\bin\perl.exe" "%1"

C:\test>argtest 1 2 3 4 5           ### NOTE ### no args printed becau
+se %* is missing above.

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

C:\test>argtest 1 2 3 4 5           ### NOTE ### Now it works.
1
2
3
4
5
[download]

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

This happens sometimes on Windows, if fairly rarely. Despite a few rounds of trying to diagnose the problem when a system was found to be having it, no universal root cause has been found, that I have seen.

I would try uninstalling Perl, making sure the configuration for .pl and "perl script" file types is fully deleted, and then re-installing Perl. I vaguely recall at least one report of this problem being resolved by some form of re-installing. You might search for prior reports of it for insights more clear than my vague memories on that specific point.

It seems likely that the problem is related in some way to these "file type associations". You can certainly just get these wrong and cause these exact symptoms. But I have seen several cases of this problem happening on systems where no obvious problem with that configuration could be identified (much more often than I've seen systems with the configurations obviously wrong).

You can work around the problem by invoking perl explicitly:

perl myscript.pl arguments go here
[download]

You can also work around the problem using pl2bat (with the various benefits and quirks that go along with that).

I don't have ActiveState Perl, but it works on portable Strawberry Perl and Windows 7:

PS C:\perl\strawberry-perl-5.18.0.1-64bit-portable\perl\bin> ./perl -e
+ " print qq/@ARGV\n/" foe bar
foe bar
[download]

In gratitude to the monks who have helped me in the past I wanted to add... I had the command line working on my Windows 7 machine and then had to re-image the hard drive for reasons I can't explain. After the re-image, the command line parameters would not work despite the assoc, ftype, and PATHEXT all being correctly set. After a frustrating day, I just started cruising the registry and found another entry for perl under HKEY_USERS\S-1-blah-blah-blah-Classes\pl_auto_file\shell\open\command. I added the %* and viola! ITS ALIVE!. Not sure why the new instance, but just wanted to throw out there for other frustrated monks. C

Thanks! I've been going crazy trying to solve exactly the same problem. I searched the registry for 'Perl.exe' and found exactly the same entry as you. Clicked 'Modify' and added the %* and all my command line arguments are now passed into the Perl script.

Thank you! I just had the same issue with Windows 10, and your suggested registry edit worked. There were several places in the registry where I added %* after the "D:\Strawberry\perl\bin\perl.exe" "%1".

In the registry, ...

Try posting the contents of n-regqueryperl.txt (the output of regqueryperl.bat )

regqueryperl.bat > n-regqueryperl.txt 2>&1

@rem @echo #~ regqueryperl.bat
@rem @echo #~ 2013-09-17-18:40:38
@rem @echo #~ 
@rem @echo #~ 
@rem @echo #~ regqueryperl.bat > n-regqueryperl.txt  2>&1
@rem @echo #~ notepad n-regqueryperl.txt  
@rem @echo #~ 
@rem @echo #~ 
@rem @echo #~ 
@setlocal

@set thisdir=%~dp0
@set thisfile=%~f0
@set thisfilebasename=%~n0
@set thisfilename=%~nx0
@echo %thisfilebasename%    %thisfilename%    %thisdir%    %thisfile%

perl -V
reg query HKLM\SOFTWARE\Perl           /s
reg query HKLM\SOFTWARE\ActiveState    /s
reg query HKCU\Software\Perl           /s
reg query HKCU\Environment             /s
reg query HKCR\PerlScript              /s
reg query HKCR\.pl                     /s
set pathext
assoc .pl
ftype perlscript
:endoffile
@endlocal
[download]

See also Re^8: redirection problem (ftype/assoc/plx hotfix) InheritConsoleHandles, Re^8: Out of date over <> and 5.10 (re-reproduce)

OMG!!!
from here

Scripts that contain standard input (STDIN) and standard output (STDOUT) may not work correctly if you start the program from a command prompt and you use a file association to start the script.

there are no rules, there are no thumbs..

This is working fine in windows 7 and ActiveState perl 5.16

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\G Montemayor>perl -e " print qq/@ARGV\n/" foe bar
foe bar

C:\Users\G Montemayor>
[download]

Take a look at What's wrong with @ARGV - or with me?.

Regards, Karl