One thing you might slightly prefer over using pl2bat might be the following cmd file:

@echo off
setlocal
set cmd=%~f0
set cmd=%cmd:~0,-4%.pl
perl -w %CMD% %*
[download]

This will (try to) invoke a Perl script (ending in .pl) in the same directory and with the same name as the .cmd file this code lives in. You could copy this file besides each Perl script you want to run from the command prompt.

But as you have set up the file associations appropriately already, likely this won't be an issue for you.

C:\test>junk junk.pl

C:\test>
[download]

That's not the behaviour the OP sees. You should be getting an error for that.

>junk junk.pl
'junk' is not recognized as an internal or external command,
operable program or batch file.

>junk < junk.pl
'junk' is not recognized as an internal or external command,
operable program or batch file.

>set PATHEXT=.pl

>junk junk.pl
'print "'$_'" while <>;
'
[download]

I suspect you messed up your test.

I suspect you messed up your test.

Sorry, the absence of error message was simply because I also had a 'junk.bat' in the same directory that did nothing silently. But it doesn't invalidate the premise.

Having deleted that, here is a full re-test in a completely virgin session, that I believe confirms the source of this old 'mystery bug':

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

c:\>cd test

c:\test>set pathext
PATHEXT=.pl;.COM;.EXE;.BAT;.CMD;

c:\test>junk junk.pl
'print "'$_'" while <>;
'
c:\test>junk < junk.pl
'print "'$_'" while <>;
'
c:\test>type junk.pl | junk
'print "'$_'" while <>;
'
c:\test>set pathext=.com;.exe;.bat;.cmd;

c:\test>set pathext
PATHEXT=.com;.exe;.bat;.cmd;

c:\test>junk junk.pl
'junk' is not recognized as an internal or external command,
operable program or batch file.

c:\test>junk < junk.pl
'junk' is not recognized as an internal or external command,
operable program or batch file.

c:\test>type junk.pl | junk
'junk' is not recognized as an internal or external command,
operable program or batch file.

c:\test>set pathexe=%pathext%.pl;

c:\test>set pathext
PATHEXT=.com;.exe;.bat;.cmd;

c:\test>set pathext=%pathext%.pl;

c:\test>set pathext
PATHEXT=.com;.exe;.bat;.cmd;.pl;

c:\test>junk junk.pl
'print "'$_'" while <>;
'
c:\test>junk < junk.pl
'print "'$_'" while <>;
'
c:\test>type junk.pl | junk
'print "'$_'" while <>;
'
c:\test>
[download]

I tried to come up with a complete test case that anybody could run, since this behavior seems to vary based on tiny things, perhaps down to unknown quirks in different environments. Perhaps this test case can be extended to cover the quirks that get discovered to the point that it demonstrates failure and success of piping / redirection in exactly the same cases on lots of different systems.

echo on

assoc .pl=perltest
perl -e"system(qq(ftype perltest=$^X \"%%1\" %%*))"
ftype perltest

mkdir pipe
cd pipe
pipe

perl -e "print 'print qq(| $_) while <>'" > pipe.pl
set pathext=.pl;.com;.exe;.bat;.cmd;
pipe pipe.pl
pipe < pipe.pl
type pipe.pl | pipe

set pathext=.com;.exe;.bat;.cmd;
pipe pipe.pl
pipe < pipe.pl

set pathext=.com;.exe;.bat;.cmd;.pl;
pipe pipe.pl
pipe < pipe.pl
type pipe.pl | pipe

del pipe.pl
cd ..
rmdir pipe
[download]

Running it myself gave me different results than BrowserUk's. First, the boring pre-amble:

C:\> echo on

C:\> assoc .pl=perltest
.pl=perltest

C:\> perl -e"system(qq(ftype perltest=$^X \"%1\" %*))"
perltest=C:\strawberry\perl\bin\perl.exe "%1" %*

C:\> ftype perltest
perltest=C:\strawberry\perl\bin\perl.exe "%1" %*

C:\> mkdir pipe

C:\> cd pipe

C:\pipe> pipe
'pipe' is not recognized as an internal or external command,
operable program or batch file.
[download]

That last line shows that I don't have an old pipe.exe or pipe.bat hanging around to confuse things.

C:\pipe> perl -e "print 'print qq(| $_) while <>'"  1>pipe.pl

C:\pipe> set pathext=.pl;.com;.exe;.bat;.cmd;

C:\pipe> pipe pipe.pl
| print qq(| $_) while <> 
C:\pipe> pipe  0<pipe.pl

C:\pipe> type pipe.pl   | pipe
[download]

The above shows that neither piping nor redirection works for me when I leave off .pl even when .pl is first in PATHEXT (the case where it worked for BrowserUk).

C:\pipe> set pathext=.com;.exe;.bat;.cmd;

C:\pipe> pipe pipe.pl
'pipe' is not recognized as an internal or external command,
operable program or batch file.

C:\pipe> pipe  0<pipe.pl
'pipe' is not recognized as an internal or external command,
operable program or batch file.
[download]

The above is the boring middle part.

C:\pipe> set pathext=.com;.exe;.bat;.cmd;.pl;

C:\pipe> pipe pipe.pl
| print qq(| $_) while <> 
C:\pipe> pipe  0<pipe.pl

C:\pipe> type pipe.pl   | pipe
[download]

The above shows that redirection and piping also fails for me when .pl at the last item in PATHEXT (the case where it also failed for BrowserUk (update:) based on my prior reading of his node but that doesn't appear to have failed for him in my latest reading of his node).

C:\pipe> del pipe.pl

C:\pipe> cd ..

C:\> rmdir pipe

C:\>
[download]

That last chunk is the boring end.

In the process of trying to get ftype / assoc to actually work, I found a lot of quirks that are possible in the Classes/.pl and Classes/testperl Registry keys. I suspect that there is something here that is important. To be clear, when I ran this test case, I had previously deleted the Class/.pl and Class/perltest Registry keys. I didn't include those steps in the test case as I figured some might find such a drastic step impolite and also because I suspect such a step would mask some of the existing quirks that cause different behavior for different people.

Somebody should probably add code to the test case that saves the keys, deletes them, and then restores them at the end. Unfortunately, the Windows Registry doesn't appear to support "rename key".

- tye        

I believe confirms the source of this old 'mystery bug'

No. If anything, you disproved it. All your tests show the correct output. None acted as if they were passed an empty or closed handle for STDIN.

Another is it screws up syntax highlighting.

Ah, yes, the piles of useful tools that I've seen discarded because they get in the way of the syntax coloring crutch continues to grow. I strongly prefer code that is easy to read without the need for colors, especially because I read code in lots of ways (in diff output, in patches, on printed pages, several different ways via revision control systems, etc.) that just don't support syntax coloring. I much prefer to be able to select my tools rather than have one fragile tool eliminating lots of other tools for me. But I realize that this places me in a small minority.

I also don't use Perl::Tidy (for similar reasons: it is rather fragile and I've seen people discard tools because they confuse the poor thing, just as you have, but also because I just don't find much benefit to it). And so using pl2bat doesn't actually require much of any "discipline" for me.

Once you have PATHEXT/ASSOC/FTYPE set up correctly, everything "Just works".

Not for everybody, at least not if you want to use piping or redirection. Or did you already forget the reason for this very thread?

And setting it up is a one-time deal.

Ah, the luxury of only ever running your code on a single computer. I'm now at a job where I have the luxury of not having to deal with a large and ever-growing list of Windows-based computers (the list of Windows-based computers I must deal with is quite small and grows only very slowly).

I also like the multiple side-by-side perl installs that it affords through the simple mechanism of using different extensions .pl for 5.latest, .pl8 for 5.8 etc.

s/simple mechanism/awkward hack/, IMHO. It must take some discipline to come up with a new extension for each new install of Perl and then to remember to update your syntax coloring configuration so that it knows about this growing list of custom extensions. ;) Using something like pl2bat means you pick which Perl to use by actually specifying the perl to use in the script, much like a #! line under Unix. pl2bat doesn't prevent using side-by-side Perl installs. It just affords them in a more straight-forward way.

I also like being able to use bl2bat-wrapped Perl scripts to change the environment or working directory of the calling command prompt (I've posted quite a few of those here). It is also useful for making scripts that can be used by my co-workers even if they don't have Perl installed on their Windows box (because my install of Perl is available via a network share).

By no means am I trying to convince you (or anyone, really) to use pl2bat. I'm just noting why, for me, the down side is so small (just the "Terminate batch job" prompting) and the up side well worth it. :)