I've seen I/O redirection broken by file associations on some systems, but not recently. I've never seen an answer as to why it is broken on some systems (but seems to work on most systems -- no obvious differences found between systems where it works vs where it doesn't). Though, it was badly broken on all systems for some early version of WindowNT (as I recall).

So you can probably stop using pl2bat, unless you have one of the rare systems that strangely still exhibit this problem.

I've put pl2bat to some good uses (CleanPath, editd, SSH Agency, vienv - Edit local environment variables on Win32, etc.), uses that wouldn't work with a *.pl file.

I never claimed that everybody would find jumping through the pl2bat hoop less painful than jumping though the PATHEXT hoop. There is already boilerplate that I include when I start a new Perl script so the extra boilerplate from pl2bat doesn't really add anything to the amount of work required to write a new Perl script (perhaps some people are just doing it wrong).

I have a lot of experience with writing Perl scripts that I want to use on lots of different (Windows) computer systems or that other people want to use on other computers. So jumping through the PATHEXT hoop over and over and over again gets old pretty fast. And using pl2bat meant that it was trivial to detect that perl.exe wasn't in the path and then to mount my network share that has Perl on it and distribute a Perl script as a *.bat file that would work on any computer in our intranet.

Running pl2bat couldn't be simpler (no options to specify, just enter the filename via tab completion), but I rarely run it anyway, at least not by hand. Most of my Perl scripts are either single-copy scripts that I just keep on my primary system as *.bat files or are in a source code repository and so there are scripts that know how to "install" them (steps such as some subset of: copy them to a directory in my $ENV{PATH}, "chmod +x" them, set the path to Perl on the #! line to work on the current system, run pl2bat, etc.).

The only thing about pl2bat that bothers me, is that sometimes I initially forget to use "call" when dealing with *.bat files calling other *.bat files.

I need pipelines and file redirection to work, and last time I looked these two were badly broken by file associations,

Hm. For as long as I've been using perl--7 years, 5.6.1 & NT4 sp1--input & output redirection and output pipelining have all worked fine using file associations:

c:\test>type echoit.pl
#! perl -sw
use strict;

print while <>;

c:\test>echoit <junk.dat
jim  14
john 23
ernest 38
matilda 43
jim 34
ernest 27
john 44
matilda 22

c:\test>echoit <junk.dat >junk.out

c:\test>type junk.out
jim  14
john 23
ernest 38
matilda 43
jim 34
ernest 27
john 44
matilda 22

c:\test>echoit <junk.dat | find "j"
jim  14
john 23
jim 34
john 44
[download]

The only (minor) inconvenience is for input piping you need to prefix the script name with 'perl':

c:\test>type junk.dat | perl echoit.pl
jim  14
john 23
ernest 38
matilda 43
jim 34
ernest 27
john 44
matilda 22
[download]

But that's more than compensated for by not having to deal with the .bat nanny prompt:

Terminating on signal SIGINT(2)
Terminate batch job (Y/N)?
[download]

And far outweighed by not having to remember to re-pl2bat if you edit the thing.

But most of all, being able to add perl switches to the command line:

perl -c script.pl
perl -d:Trace script.pl
perl -X script.pl
[download]

And finally, use perl's built-in switch parsing:

script -S=this -T=that
[download]