pipe to script requires '| perl' on win32

QM has asked for the wisdom of the Perl Monks concerning the following question:

On win32, I have a problem with reading from a pipe on STDIN only (files on the command line work as expected). I have to call the script with perl script.pl, as below.

Update: I found this and perldoc pl2bat.

Here's the script:

print while <>;
[download]

With this command

echo "one two three" | myscript.pl
[download]

I get no output, but with this

echo "one two three" | perl myscript.pl
[download]

I get

"one two three"
[download]

Is this expected behavior? [Oddly enough, using pl2bat DWIM, but I was hoping to avoid that.]

assoc and ftype give...

assoc

c:\> assoc .pl
.pl=Perl
[download]

ftype

c:\> ftype Perl
Perl="C:\Perl\bin\perl.exe" "%1" %*
[download]

-QM
--
Quantum Mechanics: The dreams stuff is made of

Comment on pipe to script requires '\| perl' on win32 Select or Download Code

Replies are listed 'Best First'.
Re: pipe to script requires '\| perl' on win32 by tachyon (Chancellor) on Apr 03, 2004 at 00:28 UTC
Is this expected behaviour? In the pl2bat docs which you even link to it is documented `This is due to a Win32 bug which Perl has no control over. This bug i +s the major motivation for B<pl2bat> [which was originally written fo +r DOS] being used on Win32 systems.` [download] So it is documented behaviour. As for expected I would have to say yes. If you expect that Win32 will let you down in various ways you are unlikely to be disappointed ;-) Windows shell functionality is perhaps best described as a somewhat neglected development area. You could also get into rant mode and question why M$ had to 'fix' stuff that was not broken and leave stuff broken that needs fixing. The bottom line is that when you go to the shell, any shell, stuff that works in one shell will not work on another shell. That is after all why they are different shells ;-) It would work using Cygwin with a shebang. cheers tachyon	[reply] [d/l]
Re: pipe to script requires '\| perl' on win32 by inman (Curate) on Apr 03, 2004 at 17:29 UTC
The Command prompt (cmd.exe) will pipe information from one 'process' to a 'thing' where the target is either an executable (.exe, .com) or a batch file (.bat, .cmd). The key is that the target must be supported directly by CMD.exe without external help. The command prompt will also 'do something' with any filename that you type in and press enter. The action carried out is the default action determined by the registry entries for the particular file extension. Normally this application is something that lets you view or edit the file. e.g. enter index.htm and IE loads the file. In the example above, the current directory contains a file called `myscript.pl`. If you enter `myscript.pl` at the command prompt, the .pl extension is associated with `Perl.exe` and so the file will be sent to `Perl.exe` with `myscript.pl` as the first argument. Since the file happens to contain some instructions that `Perl.exe` can understand, `Perl.exe` carries out the instructions. This behavior kind of makes Perl scripts look like programs in their own right since the default action sends them to `Perl.exe` and they do something. `Perl.exe` does it's own thing in the background and we kind of forget that it is running. `myscript.pl` is however still just a file and not an executable. When you try and pipe the output from another program into the `myscript.pl` file then you don't get very far since you pipe into processes not files. If on the other hand you use the explicit Perl or PL2BAT route then you are piping into a process that has `myscript.pl` as it's first argument.	[reply] [d/l] [select]