do anonymous pipes normally work on NT?

Bill Tutt billtut at microsoft.com
Wed Jun 16 23:02:18 CEST 1999


> From: radbit at my-deja.com [mailto:radbit at my-deja.com]
> 
> 
> In article <4D0A23B3F74DD111ACCD00805F31D8100DB90DDC at RED-MSG-50>,
>   Bill Tutt <billtut at microsoft.com> wrote:
> > Well, I finally noticed this thread, and I'll chime in with what I
> found out
> > so far:
> > (No, I haven't figured it all out yet, its time for sleep.)
> >
> > Symptoms:
> >  python -u cat.py < cat.py  is allowed to read from stdin.
> >  python cat.py < cat.py isn't allowed to read from stdin.
> >  python -u cat.py > blah is allowed to write to stdout
> >  python cat.py > blah isn't allowed to wrtie to stdout.
> >  python runproc.py (with -u) cat.py isn't allowed to write to stdout
> >  python runproc.py cat.py isn't allowed to write to stdout.
> >
> > -u does two things:
> > 1) turns stdin/stdout into binary streams
> > 2) turns off stdio buffering
> 
> Hi
> 
> maybe I'm missing something about what you are looking for: here are 2
> test scripts that work as anonymous pipes:
> 

That's not the question... Anonymous pipes on NT work wonderfully. (just not
the way we're expecting from this particular Python context) 
Calling SetStdHandle() is particularly silly as well, you shouldn't need to
overwrite the current stdout just to get this to work.

> win32file.WriteFile(std_out, 'this method works....')
> 

Calling GetStdHandle shouldn't be necessary either. The CRT already grabbed
that information for us when Python started up.

The question is why does sys.stdout.write() not seem to work without -u when
the above line works wonderfully.... I'm not worried about a working example
of anonymous pipes in general, thats the easy part.

Bill




More information about the Python-list mailing list