In IDLE, PythonWin or other non-console interactive Python under Windows: >>> from subprocess import * >>> Popen('cmd', stdout=PIPE) Traceback (most recent call last): File "<pyshell#11>", line 1, in -toplevel- Popen('', stdout=PIPE) File "C:\python24\lib\subprocess.py", line 533, in __init__ (p2cread, p2cwrite, File "C:\python24\lib\subprocess.py", line 593, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\python24\lib\subprocess.py", line 634, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required The same command in a console windows is successful. Why it happens: subprocess assumes that GetStdHandle always succeeds but when there is no console it returns None. DuplicateHandle then complains about getting a non-integer. This problem does not happen when redirecting all three standard handles. Solution: Replace None with -1 (INVALID_HANDLE_VALUE) in _make_inheritable. Patch attached.
This patch looks very interesting. However, it feels a little bit strange to call DuplicateHandle with a handle of -1. Is this really allowed? What will DuplicateHandle return in this case? INVALID_HANDLE_VALUE? In that case, isn't it better to return INVALID_HANDLE_VALUE directly?
If you duplicate INVALID_HANDLE_VALUE you get a new valid handle to nothing :-) I guess the code really should not rely on this undocumented behavior. The reason I didn't return INVALID_HANDLE_VALUE directly is because DuplicateHandle returns a _subprocess_handle object, not an int. It's expected to have a .Close() method elsewhere in the code. Because of subtle difference between in the behavior of the _subprocess and win32api implementations of GetStdHandle in this case solving this issue this gets quite messy! File Added: subprocess-noconsole2.patch
