do anonymous pipes normally work on NT?

[Bill Tutt]

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

The binary thing shouldn't make any difference. The stdio thing might make a
difference, but how isn't obvious from the read.c source code.

Now the big mystery is: Why does the CRT care? (prolly need to debug read.c
to find out) 
The 2nd question is: Why doesn't -u fix the runproc.py case?

I think the answer to the 2nd question may come from the
	::InitializeSecurityDescriptor(&m_sd, SECURITY_DESCRIPTOR_REVISION);
line in PySECURITY_ATTRIBUTES's constructor.

I'm guessing (not having debug bits atm) that this causes a security
descriptor that doesn't have the default permissions that the current
process has to become filled in. 

(Default permissions are inferred from the current process/thread if
lpSecurityDescriptor is NULL)  

This in turn causes reading/writing to the inherited handles to be denied
because the new process doesn't have the correct permissions. Which in turn
turns into errno == EBADF in read.c.


This seems to be the only meaningful difference between the Python code in
runproc.py, and the win32popen.cpp code I wrote...

So the first thing to try might be to try commenting out the
InitializeSecurityDescriptor line, and rebuilding pywintypes15.dll, and then
using -u when running cat.py.

The next thing to do is to debug _read.c (in the MS CRT) and see why its
complaining if -u isn't specified on the command line.

If somebody could help explore where exactly errno is getting set to EBADF
during the non- "runproc.py" cases that'd be a great help.

Bill
Not part of product support, or PR.