do anonymous pipes normally work on NT?
Bill Tutt
billtut at microsoft.com
Wed Jun 16 08:15:23 EDT 1999
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.
More information about the Python-list
mailing list