title: How do I make Perl scripts recognize parameters in the Win32 cmd console?
body: <p>When I invoke my Perl scripts in the Windows environment without invoking <code>perl</code> first, the parameters are not passed to my script.</p>
  
  <p>For example,</p>
  
  <pre><code>C:\&gt; C:\my-perl-scripts\foo.pl bar
  </code></pre>
  
  <p>invokes <code>foo.pl</code> but doesn't recognize <code>bar</code> as a parameter (<code>@ARGV</code> is empty). However, </p>
  
  <pre><code>C:\&gt; perl C:\my-perl-scripts\foo.pl bar
  </code></pre>
  
  <p>works as expected.</p>
  
  <p>Is this a configuration issue?</p>
  
  <p>Ideally, I'd like to be able to distribute some perl scripts, have the user add <code>C:\my-perl-scripts\</code> to the path and then just be able to invoke <code>foo.pl</code> from anywhere while running cmd.</p>
  
  <p>If they have to specify perl first, then they'll always have to give a complete path.</p>
  
  <p>Any ideas or recommendations?</p>
  
  <p><strong>Edit:</strong> To show that the assoc and ftype are correct on my system, I executed the following commands.</p>
  
  <pre><code>C:\&gt;assoc .pl
  .pl=Perl
  
  C:\&gt;ftype Perl
  Perl="C:\Perl\bin\perl.exe" "%1" %*
  
  C:\&gt;more t.pl
  print "'$_'\n" for @ARGV;
  
  C:\&gt;t a b
  
  C:\&gt;perl t.pl a b
  'a'
  'b'
  
  C:\&gt;t.pl a b
  
  C:\&gt;
  </code></pre>
  
  <p>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.</p>
  
  <p>I'm not sure where to look next, but thanks for the suggestions so far. They have been very helpful.    </p>
  
  <p><strong>Edit 2:</strong> 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.</p>
  
  <p><strong>Edit 3:</strong> 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).</p>