Redirecting output in Windows NT

[Bengt Richter]

On Wed, 13 Mar 2002 02:26:06 GMT, Syver Enstad <syver-en+usenet at online.no> wrote:

>peter.schwalm at epost.de (Peter Schwalm) writes:
>
>> > >It is a bug in the NT command prompt.  Works OK in Win2k.  I
>> believe
>> 
>> > >there is a FAQ on it too.
>> > >
>> You state that *output* redirection works OK in Win2k. I could verify
>> that, but unfortunately it's not true for the redirection of *input*.
>> If I want to redirect input, I still have to use the form
>> 
>>     python myprog.py <inputfile
>> 
>> instead of the simpler
>> 
>>     myprog <inputfile
>
>Yes, this is a pain in the ass to say the least. Especially since
>myprog.py has to be in the current directory(or be fully specified) in
>the first version, while it just has to be situated in the os path in
>the second.
>
If you wrap it in a .cmd file the myprog.cmd doesn't have to be fully specified,
just on the path. It probably pays to specify the path to the script fully inside
the wrapped command unless you want the other effect., since it avoids searches,
might as well specify python.exe fully too. But I didn't in the following.
Your "myprog < inputfile" works:

--
 >echo "This is text in inputfile." > inputfile

 >type myprog.py
 import sys
 sys.stdout.write(sys.stdin.read())

 >type myprog.cmd
 @python myprog.py %*

 >myprog < inputfile
 "This is text in inputfile."

 >myprog < inputfile >outputfile

 >type outputfile
 "This is text in inputfile."
--
>Has anyone pointers to any information regarding this problem, which
>is an OS problem as far as I can see. It leads to Python programs not
>being quite real executables under the win2k and probably other win32
>os'es, which is a shame since Python is such an intensely practical
>tool.
>
I just use .cmd wrapping and put my utilities in c:\util and have
that on the path. It's a minor pain, but then you can type normally.

BTW, if you set the PATHEXT variable in NT4 (don't know others for sure)
to include .PY, then you can type myprog without the .py and the search
will go through the path for .py, .com, .bat, .exe, and whatever.
set PATHEXT=.PY;.COM;.EXE;.BAT;.CMD will give priority to myprog.py
over myprog.exe, etc. (though you don't want to put .PY first, because
then you can't call a .cmd wrapper of the same name without using the
extension, and you still have to wrap if you want to redirect i/o).

I tried setting up a test association of .pyt to cmd.exe right in the
ftype setting, and and it works, but still no redirection. Maybe it's
possible to write a special launcher and associate to that, but if
it is, it will probably take some horrible special-code-in-title-bar
windows search for parent or something like that.

IIRC, some Perl hackers facing the problem worked up some Rube Golberg
thing to get the proper effect without wrapping, but I don't think it
was 100.000%.

Quite a while ago I wrote a win32 prog which read stdin fed by a pipe,
and there were a lot of hoops to jump though in order to get all the
data reliably and not get broken pipes, as I recall. It struck me as
really ugly at the time, and I think they had some pipe problems, so
maybe it's part of the same syndrome. If they finally fixed it in win2k,
great (assuming the EULA is acceptable, and I can install w/o internet).

Anyway, ISTM the windows legacy was about windows messages and polling loops,
with stdio pretty much relegated to DOS programs accessing virtualized BIOS
through c stdio library modules, running in a VDM. I'd guess stdio didn't
get its share of attention outside of the DOS or pseudo-DOS environment,
and wasn't a primary element in architecting cooperative processes at first.

I.e., try to ignore Unix and you will be doomed to re-inventing it incrementally ;-)

>I've tried some Google searches for this problem, but have not come up
>with anything. How are other scripting languages doing?
>
It is the same for Perl, and will work the same for any interpreter or
program started by file extension association, unless it is a native
executable, I believe.

Hm... I'd bet you could do what self-extracting zip files do, though. They have
a native .exe part that gets run normally, and the data is incorporated in
the .exe file. I'd bet you could make a python script launcher somehow that
way (not by prefixing the whole interpreter, obviously, but exec-ing it). It
might mean making the python interpreter recognize how to skip an .exe prefix
when it gets control (new invocation option?) to avoid unnecessary copying,
but it feels doable.

Thinking via keyboard again...

Regards,
Bengt Richter