• Posting a snippet of the script(s) for further investigation
• Posting the command line invocation of the script(s)
• Posting the Data::Dumper results of @ARGV

#
# Your code 
#
use Data::Dumper;
print Dumper( \@ARGV );

#
# More code
#
[download]

You are calling your Perl script like this:

system('my_perl_script.pl', 'arg1', 'arg2');
[download]

This does not pass the commands to Perl or the Perl script. You need to invoke the Perl interpreter with your script as the parameter:

my @cmd = $^X, '-w', 'my_perl_script.pl', 'arg1', 'arg2';
system( @cmd ) == 0
  or die "Couldn't launch @cmd: $! / $?";
[download]

If you are starting your Perl script from the command line, you also cannot start it like this:

C:\>my_perl_script.pl arg1 arg2
[download]

but you need to start it like this:

perl -w my_perl_script.pl arg1 arg2
[download]

Of course, this is guesswork based on your description. Usually it helps when you post a minimal script that exhibits the problematic behaviour, and the test cases.

The 'C:\>my_perl_script.pl arg1 arg2' does work when you have specified perl as the default for the pl extension and have included the shebang line in the script.

Windows doesn't read the shebang line. Perl in Windows does parse the shebang line (unlike Perl in unix, which treats it like any other comment), but not for the reason you mentioned.

Update: Corrected problems identified by Celada. Verification of what he/she said:

$ uname -sr
FreeBSD 5.4-RELEASE-p8
$ cat a.pl
#!/usr/bin/perl -w
print undef;
$ a.pl
Use of uninitialized value in print at ./a.pl line 2.
$ perl a.pl
Use of uninitialized value in print at a.pl line 2.
[download]

No, it does not. It does not pass the arguments. As you found out.

The actual code is extensive, so I created a smaller version to demonstrate the ARGV problem.

#!/perl/bin/perl -w
# IEL - Interface Engine Lite
# IELmqsvr - Interface MQ Series Server script
#              - This script establishes a tcp/ip socket with the rece
+iving system and interagates
#                the MQ Series Queue for transactions to send.  
#              - Creation Date - 8/30/05
#              - Modification Log -
# 

# This section declares system Modules and Variables
require 5.002;
use IO::Select;
use Env;
use IO::Handle;
use strict;
use Errno qw(EAGAIN);
use IO::Socket;
use sigtrap;


my ($INAME);
$INAME = $ARGV[0];
print STDOUT "ARGV = @ARGV - 0 = $ARGV[0]\n";
exit;
[download]

Here is a sample run.

C:\IEL\bin>ARGVtst.pl LHW_TST
Use of uninitialized value in concatenation (.) or string at C:\IEL\bi
+n\ARGVtst.
pl line 23.
ARGV =  - 0 =

C:\IEL\bin>
[download]

Once again any help will be appreciated.

Treating .pl files as executables in Windows is iffy at best. Try
perl ARGVtst.pl LHW_TST
instead of
ARGVtst.pl LHW_TST

And here is the same test ran on my windows 2000 system.

C:\IEL\bin>ARGVtst.pl LHW_TST
ARGV = LHW_TST - 0 = LHW_TST

C:\IEL\bin>
[download]

>assoc .pl
.pl=Perl
>ftype Perl
Perl="E:\Perl\bin\perl.exe" "%1" %*
[download]

This (path to perl.exe according to your machine) would assure you, that your Perl is properly installed.

You should be able to call perl scripts just by name.

You can can even go further and:

Under these circumstances

>echo print "@ARGV" >targ.pl

>targ 1 2 3
1 2 3
>perl -e "system 'targ', 1, 2"
1 2
[download]

But, I've seen that misbehaviour (script name triggers execution, but @ARGV is not available) reported a few times in the past (for W2K and XP). Heck, I even had once such a machine (NT4) years ago at work, but did not know enough then about perl and Windows command execution to solve the mystery.

In all these cases a call of perl with the script (and its parameters) as argument was processed correctly.

I will sleep better, once someone is able to explain what causes this (and I can read it somewhere posted) ;-)

And Celada++ for the post right on spot wrt Shebang parsing.

I use pl2bat (included in Win32-perl's 'bin' directory) and so don't have to worry about this. But it is more because you shouldn't have to know what language tool X is written in just to use X. So I never run perl scripts via "script.pl ..." nor via "perl script...".

I've rewritten tools between Perl, *.cmd, C++, etc. and don't need to retrain my fingers much less have to find and update other tools that happen to use the rewritten tool.

- tye        

...nor via "perl script...".

Well, you do... your pl2bat generated batch files do it for you...

I see your point, but as someone who long abandonded maintaining dual language scripts (since my change from using Perl5 instead of Perl4 and using WinNT, which gave me a way to just declare .pl files "executable") and someone who is supposed to support Win at work, I prefer not to ignore this "1 in a million" problem, but seek for a proper explanation/fix.

I started searching the web again and found some threads in another site that addressed this problem. It seems that this is an old problem that has been migrating from on windows version to the next.

The first threads from 1998 were about Win 98 having the problem. The next set addressed Win 98 working, but NT having the problem. Then there were problems where NT worked but 2000 had a problem.

Finally, there was a thread where XP Prof failed, but XP Home was fine. In this thread there was an attachment that offered a solution to the problem.

The author said the problem was in the registry key 'HKEY_CLASSES_ROOT\Perl\shell\Open\command'. The value of this key should be '"C:\Perl\bin\perl.exe" "%1" %*', but the '%*' was being left off.

I could not find HKEY_CLASSES_ROOT in my registry, so I searched for perl.exe. I found a Perl\shell\Open\command under a different path and sure enough the '%*' was missing. I added the %* and the command now works as designed when entering 'ARGVtst.pl LHW_TST'.

Thanks to all of you who had input into this problem. I would like to give credit to the author of the attachment on the other web page, but I don't know the rules about mentioning someone else name or giving the name of a different site.

This is relevant even today, in case one is using Strawberry Portable, and wants it to behave as normal perl installation. Thanks for the tip!