[issue10739] Subprocess behavior on Windows

Georg Brandl added the comment: I agree that this belongs in the makefile docs. Fixed in r87535. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker

[issue10739] Subprocess behavior on Windows

R. David Murray added the comment: I think I'll leave that decision up to the doc crew. My thought was that makefile was supposedly returning a file, therefore it was appropriate to document there that it wasn't really a file on windows, whereas subprocess docs are only talking about files,

[issue10739] Subprocess behavior on Windows

Ross Lagerwall added the comment: Since the code in subprocess gets the underlying fileno of the file-like object (line 819 of subprocess.py), I presume it is an example of the general problem of files and sockets not mixing very well on Windows. So, I have attached a patch to document this i

[issue10739] Subprocess behavior on Windows

R. David Murray added the comment: This might be an example of the general problem that on windows, sockets and files don't mix well. You can't use a file in a select call, either. I think there are two possibilities here: either makefile doesn't produce anything very useful on windows, or t

[issue10739] Subprocess behavior on Windows

Ross Lagerwall added the comment: Attached is a patch to document this. -- keywords: +patch Added file: http://bugs.python.org/file20116/subprocessdoc.diff ___ Python tracker __

[issue10739] Subprocess behavior on Windows

New submission from Ross Lagerwall : On Windows, creating a subprocess does not work when stdin (or stdout or stderr) is set as a file object created from socket.makefile(). An IOError is thrown. This works fine on Unix so I assume it is a platform limitation rather than a Python bug. If thi