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".

Here's what I get. Everything works. (At least how I would expect it to.)

c:\test>pipetest

c:\test>echo on

c:\test>assoc .pl=perltest
.pl=perltest

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

c:\test>ftype perltest
perltest=C:\Perl64\bin\perl.exe "%1" %*

c:\test>mkdir pipe

c:\test>cd pipe

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

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

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

c:\test\pipe>pipe pipe.pl
| print qq(| $_) while <>
c:\test\pipe>pipe  0<pipe.pl
| print qq(| $_) while <>
c:\test\pipe>type pipe.pl   | pipe
| print qq(| $_) while <>
c:\test\pipe>set pathext=.com;.exe;.bat;.cmd;

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

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

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

c:\test\pipe>pipe pipe.pl
| print qq(| $_) while <>
c:\test\pipe>pipe  0<pipe.pl
| print qq(| $_) while <>
c:\test\pipe>type pipe.pl   | pipe
| print qq(| $_) while <>
c:\test\pipe>del pipe.pl

c:\test\pipe>cd ..

c:\test>rmdir pipe
[download]

Thank you! Would you consider saving off then deleting your Classes/.pl registry key and trying the test case again? (Any other attempts to find quirks that impact this problem also appreciated.)

- 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.