This sounds like a bug with file associations in Win32. Read the documentation for pl2bat (included with Perl, probably in the bin directory) for lots of more information.

Update: Here is the documentation for everyone's convenience:

=head1 DESCRIPTION

This utility converts a perl script into a batch file that can be
executed on DOS-like operating systems.  This is intended to allow
you to use a Perl script like regular programs and batch files where
you just enter the name of the script [probably minus the extension]
plus any command-line arguments and the script is found in your
B<PATH> and run.

=head2 ADVANTAGES

There are several alternatives to this method of running a Perl
script.  They each have disadvantages that help you understand the
motivation for using B<pl2bat>.

=over

=item 1

    C:> perl x:/path/to/script.pl [args]

=item 2

    C:> perl -S script.pl [args]

=item 3

    C:> perl -S script [args]

=item 4

    C:> ftype Perl=perl.exe "%1" %*
    C:> assoc .pl=Perl
    then
    C:> script.pl [args]

=item 5

    C:> ftype Perl=perl.exe "%1" %*
    C:> assoc .pl=Perl
    C:> set PathExt=%PathExt%;.PL
    then
    C:> script [args]

=back

B<1> and B<2> are the most basic invocation methods that should work
on any system [DOS-like or not].  They require extra typing and
require that the script user know that the script is written in 
Perl.  This is a pain when you have lots of scripts, some written in
Perl and some not.  It can be quite difficult to keep track of which
scripts need to be run through Perl and which do not.  Even worse,
scripts often get rewritten from simple batch files into more
powerful Perl scripts in which case these methods would require all
existing users of the scripts be updated.

B<3> works on modern Win32 versions of Perl.  It allows the user
to omit the ".pl" or ".bat" file extension, which is a minor
improvement.

B<4> and B<5> work on some Win32 operating systems with some command
shells.  One major disadvantage with both is that you can't use them
in pipelines nor with file redirection.  For example, none of the
following will work properly if you used method B<4> or B<5>:

    C:> script.pl <infile
    C:> script.pl >outfile
    C:> echo y | script.pl
    C:> script.pl | more

This is due to a Win32 bug which Perl has no control over.  This bug
is the major motivation for B<pl2bat> [which was originally written
for DOS] being used on Win32 systems.

Note also that B<5> works on a smaller range of combinations of
Win32 systems and command shells while B<4> requires that the user
know that the script is a Perl script [because the ".pl" extension
must be entered].  This makes it hard to standardize on either of
these methods.

=head2 DISADVANTAGES

There are several potential traps you should be aware of when you
use B<pl2bat>.

The generated batch file is initially processed as a batch file
each time it is run.  This means that, to use it from within another
batch file you should preceed it with C<call> or else the calling
batch file will not run any commands after the script:

    call script [args]

Except under Windows NT, if you specify more than 9 arguments to
the generated batch file then the 10th and subsequent arguments
are silently ignored.

Except when using F<CMD.EXE> under Windows NT, if F<perl.exe> is
not in your B<PATH>, then trying to run the script will give you a
generic "Command not found"-type of error message that will probably
make you think that the script itself is not in your B<PATH>.  When
using F<CMD.EXE> under Windows NT, the generic error message is
followed by "You do not have Perl in your PATH", to make this
clearer.

On most DOS-like operating systems, the only way to exit a batch
file is to "fall off the end" of the file.  B<pl2bat> implements
this by doing C<goto :endofperl> and adding C<__END__> and
C<:endofperl> as the last two lines of the generated batch file. 
This means:

=over

=item No line of your script should start with a colon.

In particular, for this version of B<pl2bat>, C<:endofperl>,
C<:WinNT>, and C<:script_failed_so_exit_with_non_zero_val> should
not be used.

=item Care must be taken when using C<__END__> and the C<DATA>
file handle.

One approach is:

    .  #!perl
    .  while( <DATA> ) {
    .      last   if  /^__END__$/;
    .      [...]
    .  }
    .  __END__
    .  lines of data
    .  to be processed
    .  __END__
    .  :endofperl

The dots in the first column are only there to prevent F<cmd.exe>
to interpret the C<:endofperl> line in this documentation. 
Otherwise F<pl2bat.bat> itself wouldn't work.  See the previous
item.  :-)

=item The batch file always "succeeds"

The following commands illustrate the problem:

    C:> echo exit(99); >fail.pl
    C:> pl2bat fail.pl
    C:> perl -e "print system('perl fail.pl')"
    99
    C:> perl -e "print system('fail.bat')"
    0

So F<fail.bat> always reports that it completed successfully. 
Actually, under Windows NT, we have:

    C:> perl -e "print system('fail.bat')"
    1

So, for Windows NT, F<fail.bat> fails when the Perl script fails,
but the return code is always C<1>, not the return code from the
Perl script.

=back
[download]

Thanks for that!
I was banging my head against the wall a bit for this one, and wondered if <Sharp Intake of Breath> Perl itself was the problem, or if it was me! Glad to know it's an Windows problem.

Rudif's tip also works - thanks: interesting to see the comment that cmd isn't a "real shell": I'm trying to write this filter, and other utilities, to make working in cmd a bit more bearable.

Cheerio!
Osfameron

if you were to make a test file called test.pl with the lines
#!/usr/bin/perl -w
print <STDIN>;

in it, then do a "cat test.pl |./test.pl"
it would print:
#!/usr/bin/perl -w
print <STDIN>;

-Ryan

Yes, pipes don't pass stuff via @ARGV, but <> does read from STDIN if @ARGV is empty. So <> is appropriate and that is not the problem.

        - tye (but my friends call me "Tye")