subprocess considered harmfull?

[Uri Nix]

Hi all,

I've been trying to use (Python 2.4 on WinXP) the subprocess module to
execute a shell command (nmake in this case), and pass its output to a
higher level.

Using the following snippet:
p =
subprocess.Popen(nmake,stderr=subprocess.PIPE,stdout=subprocess.PIPE, \
universal_newlines=True, bufsize=1)
os.sys.stdout.writelines(p.stdout)
os.sys.stdout.writelines(p.stderr)
Works fine on the command line, but fails when called from within
Visual Studio, with the following error:
File "C:\Python24\lib\subprocess.py", line 549, in __init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 609, in _get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 650, in _make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

If I replace the functionality with:
p = os.popen4(nmake)
# p[1] = stdout_and_stderr result pipe
p[1].flush()
os.sys.stdout.writelines(p[1].readlines())
All is well.

I have a feeling this has been encountered before (by googling here),
but didn't see any concise answer as to subprocess' robustness.
So what is the matter here? And should I consider the subprocess
module still unstable?

Cheers,
Uri

 

[Do Re Mi chel La Si Do]

Hi also !

In other fields, I also found uses which did not function with subprocess,
but OK with popen2/4

@-salutations

Michel Claveau

 

[Steven Bethard]

Using the following snippet:
p =
subprocess.Popen(nmake,stderr=subprocess.PIPE,stdout=subprocess.PIPE, \
universal_newlines=True, bufsize=1)
os.sys.stdout.writelines(p.stdout)
os.sys.stdout.writelines(p.stderr)
Works fine on the command line, but fails when called from within
Visual Studio, with the following error:
File "C:\Python24\lib\subprocess.py", line 549, in __init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 609, in _get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 650, in _make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

This looks like these known bugs:
http://python.org/sf/1124861
http://python.org/sf/1126208

Try setting stderr to subprocess.PIPE. I think that was what worked for
me. (You might also try setting shell=True. That's what I currently
have in my code that didn't work before.)

STeVe

 

[Fredrik Lundh]

This looks like these known bugs:
http://python.org/sf/1124861
http://python.org/sf/1126208

Try setting stderr to subprocess.PIPE. I think that was what worked for
me. (You might also try setting shell=True. That's what I currently
have in my code that didn't work before.)

if someone wants to investigate, is seeing this problem, and have the win32
extensions on their machine, try changing this line in subprocess.py:

if 0: # <-- change this to use pywin32 instead of the _subprocess driver

to:

if 1: # <-- change this to use _subprocess instead of the pywin32 driver

and see if it either fixes the problem (not very likely) or gives you a better
error message (very likely).

</F>

 

[Roger Upole]

if someone wants to investigate, is seeing this problem, and have the win32
extensions on their machine, try changing this line in subprocess.py:

if 0: # <-- change this to use pywin32 instead of the _subprocess driver

to:

if 1: # <-- change this to use _subprocess instead of the pywin32 driver

and see if it either fixes the problem (not very likely) or gives you a better
error message (very likely).

</F>

The error msg is only slightly better:

error: (6, 'DuplicateHandle', 'The handle is invalid.')

Basically, gui apps like VS don't have a console, so
GetStdHandle returns 0. _subprocess.GetStdHandle
returns None if the handle is 0, which gives the original
error. Pywin32 just returns the 0, so the process gets
one step further but still hits the above error.

Subprocess.py should probably check the
result of GetStdHandle for None (or 0)
and throw a readable error that says something like
"No standard handle available, you must specify one"

Roger

 

[Uri Nix]

The error msg is only slightly better:

error: (6, 'DuplicateHandle', 'The handle is invalid.')

Basically, gui apps like VS don't have a console, so
GetStdHandle returns 0. _subprocess.GetStdHandle
returns None if the handle is 0, which gives the original
error. Pywin32 just returns the 0, so the process gets
one step further but still hits the above error.

Subprocess.py should probably check the
result of GetStdHandle for None (or 0)
and throw a readable error that says something like
"No standard handle available, you must specify one"

Roger

I gathered as much about why this happens in VS. A further question is
why does n't os.popen fall in the same trap?

Cheers,
Uri

 

[Roger Upole]

I gathered as much about why this happens in VS. A further question is
why does n't os.popen fall in the same trap?

Cheers,
Uri

From a quick glance at the source, it looks like it always
creates new pipes.

Roger