@ARGV is empty using ActivePerl in Windows 7

Question

I have the following Perl script. I am trying to run it in Windows 7 using ActivePerl:

#!c:\Perl64\bin\perl.exe -w

use strict;

my $mp3splt_exe = 'c:\Program Files (x86)\mp3splt\mp3splt.exe';

my $mp3splt_args = '-o "@n @f" -g "r%[@o @N]"  -f -t 6.0';

print @ARGV;
my $filename = $ARGV[0];

print "$mp3splt_exe $mp3splt_args $filename\n";

(as you can see, I am trying to create a wrapper for mp3splt :-) )

When I run it like this:

C:\Program Files (x86)\mp3splt>run_mp3splt.pl a

I get this:

Use of uninitialized value $filename in concatenation (.) or string at C:\Program Files (x86)\mp3splt\run_mp3splt.pl line 12.
c:\Program Files (x86)\mp3splt\mp3splt.exe -o "@n @f" -g "r%[@o @N]"  -f -t 6.0

So, first of all, when I print @ARGV, nothing gets printed, and second of all, when I assign $filename = $ARGV[0], $filename is undef, so I get the warning.

So... what am I doing wrong? Why isn't the commandline parameter being passed to the script?

Unstep

Right this is really strange, because I just ran the snippet on my Win7 box and it actually worked. What version of perl are you using, and have you installed the appropriate one for Windows 7? Also try to run this perl -e "print @ARGV" aaaa And see if you get any output, if you don't then there is definitely something wrong with your perl installation. If you do, you probably have some conflicts in the script, check for scope of declared variables etc. – Looker

Answer 1

I'm pretty sure Windows 7 doesn't understand the shebang line. What happens if you run this with perl run_mp3splt.pl a?

Suppletion

Shebang cannot be the problem. Windows uses extension association. The ActiveState installer associates '.pl' files with perl. – Dogmatize

Answer 2

As others have pointed out perl blah.pl asdf works, while blah.pl asdf fails. This is because when you run the perl script directly, Windows realizes it must call perl, and uses the rule perl "%1", which only passes the script name to perl, not any of the parameters.

To fix this, you have to tell windows to use the rule perl "%1" %*

How to do that can be a little tedious:

Option 1

According to perlmonks, you should be able to use assoc and ftype on the commandline. In fact, if you type help ftype, it tells you how to setup perl:

assoc .pl=PerlScript
ftype PerlScript=perl.exe %1 %*

To run assoc requires cmd run as administrator on Window 7.

However, this didn't work for me. Windows ignored the association. I had to modify the registry. This may be due to the misguided advice to run the Default Programs utility on Win 7, which lets you specify the program to use for given file extensions. Unlike XP, this will not allow you to specify multiple command options (to be used in the right-click menu) -- it will only allow you to specify the program that is used when you double-click on a file (or run foo.pl from commandline).

Option 2

Modify the registry: HKEY_CLASSES_ROOT

If you've used the assoc/ftype commands, you may have entries for perl or PerlScript. As I said earlier, these will be ignored. Look for pl_auto_file, and drill down to the command:

HKCR\pl_auto_file\shell\open\command

Here the (Default) should be set to something like: "C:\Perl\bin\perl.exe" "%1"

Add the missing %* on the end of that and you should be good to go: "C:\Perl\bin\perl.exe" "%1" %*

No reboot necessary.

Option 3

If you're lazy and trusting, you can try using this as a reg file, and importing it into your registry:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\pl_auto_file\shell\open\command]
@="\"C:\\Perl\\bin\\perl.exe\" \"%1\" %*"

This should be sufficient to make blah.pl asdf work.

Eleonoreleonora

Additionally (for options 2&3), there may be an existing, per-user key that would override this location. Such as: HKEY_USERS\S-X-X-XX-XXXXXXX-XXXXXX-XXXXXXX-XXXX\Software\Classes\pl_auto_file. I would recommend removing this key completely, and using the one that is in option 2 or option 3. However, you could also just edit this key (and then the change would only work for your user). – Demb

Answer 3

I've had the problem that if I executed on Win7:

perl myprog.pl a b c  

the program got the parameters (in @ARGV) correctly, but if I executed:

myprog.pl a b c 

the program would NOT receive the parameters.

I searched the web for a solution and soon found that it was no ActiveState perl problem but more likely a filetype association problem in Windows (Win7), (thanks to the PerlMonks website).

However all solutions changing the

assoc .pl=Perl  

and the

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

did not solve the puzzle for me. I did notice that the assoc .pl was not used somehow because if I added assoc .plx=Perl and renamed my program to myprog.plx

myprog.plx a b c 

worked perfectly !

So then I read this problem on the Microsoft forum were the Win7 "feature" Default Programs was mentioned, I found the solution to my problem:

Open Default Programs by clicking the Start button , and then click "Default Programs".

Select "Associate a file type or protocol with a program" and select ".pl" and click on "Change program". There was already a Perl Command Line Interpreter specified as Recommended Programs but instead I clicked on Browse and selected the Perl.exe myself. After closing the "Associate a file type ..." screen,

myprog.pl a b c 

executed like a charm, all parameters were correctly retrieved by my program.

Hope that helps...

Wry

The key here is to browse and pick your exe explicitly. I spent hours looking over my setup and everything seemed right. I did this and it worked perfectly! Thanks! – Bluecoat

Answer 4

Perl ARGV problem solution in Windows 8.1:

HKEY_CLASSES_ROOT\Applications\perl.exe\shell\open\command = "C:\Perl\bin\perl.exe" "%1" %*

No re-boot needed.

Lazo