When using a socket._fileobject as stdin or stdout, subprocess.Popen fails: Traceback (most recent call last): ... File "c:\Python25\lib\subprocess.py", line 586, in __init__ errread, errwrite) = self._get_handles(stdin, stdout, stderr) File "c:\Python25\lib\subprocess.py", line 680, in _get_handles p2cread = msvcrt.get_osfhandle(stdin.fileno()) IOError: [Errno 9] Bad file descriptor Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback. Usage: 1) In one shell start tst_subprocess_socket.py 2) In a second shell start tst_subprocess_socket_client.py 3) On Window, the server will fail and produce the obove traceback.
This is a known limitation of Windows; unlike UNIX like systems, it treats sockets and file descriptors as completely different entities. I don't think there is anything that Python can do to hide this difference.
Correct In Windows file descriptors are handled by the MSVCR library and socket descriptors by winsock (ws32*). For the same reason you can't use a fd with select on Windows. wont fix == Can't fix Windows
"Can't Fix" that is not true. I've just fixed this in 2.7 with a trivial change to subprocesss.py, I think it'd work in over versions too. Note that type shenanigans are already in play in _get_handles, it's looking at the types of the parameters being passed in to decide how to get a hold of the "handle". The socket module makes a duck type of the file object. The fileno() method of the socket object returns a handle not a CRT file descriptor. This is exactly the kind of handle that _get_handles() is looking for. So all that is needed is one more "if" to the sequence of how to get the "handle" which for a socket object would be just stdin.fileno() etc. I've just tested this in a fairly complicated remote job queuing software (a commercial product) that has the ability to connect the spooler (on one machine) with an arbitrary server machine (linux, osx and now windows) via a socket. The job is launched with subprocess.Popen and sockets are wired into the stdin,stdout and stderr. Works beautifully now. I've attached a patch file made with: $ diff -c subprocess.py.ORIG subprocess.py > subprocess.py.patch Apply with: $ cd Python-2.7.1/Lib ; patch -p0 < c:/temp/subprocess.py.patch Cheers, - James
