[ python-Bugs-1227748 ] subprocess: inheritance of std descriptors inconsistent

[SourceForge.net]

Bugs item #1227748, was opened at 2005-06-26 15:37
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227748&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: André Malo (ndparker)
Assigned to: Peter Ã…strand (astrand)
Summary: subprocess: inheritance of std descriptors inconsistent

Initial Comment:
The inheritance of std descriptors is inconsistent
between Unix and Windows implementations.

If one calls Popen with stdin = stdout = stderr = None,
the caller's std descriptors are inherited on *x, but
not on Windows, because of the following optimization
(from subprocess.py r1.20):

   655	        def _get_handles(self, stdin, stdout,
stderr):
   656	            """Construct and return tupel with
IO objects:
   657	            p2cread, p2cwrite, c2pread,
c2pwrite, errread, errwrite
   658	            """
   659	            if stdin is None and stdout is None
and stderr is None:
   660	                return (None, None, None, None,
None, None)
   661	

I suggest to just remove those lines 659 and 660. The
current workaround is to duplicate the handles by the
application and supply an own STARTUPINFO structure.

----------------------------------------------------------------------

>Comment By: Peter Ã…strand (astrand)
Date: 2007-01-29 21:54

Message:
Logged In: YES 
user_id=344921
Originator: NO

>If one calls Popen with stdin = stdout = stderr = None,
>the caller's std descriptors are inherited on *x, but
>not on Windows, 

This is a correct observation. However, the current implementation is not
necessarily wrong. This could instead be seen as a consequence of the
different environments. The subprocess documentation states that "With
None, no redirection will occur". So, it becomes an interpretation of what
this really mean. Since the "default" behaviour on UNIX is to inherit and
the default behaviour on Windows is to attach the standard handles to (an
often newly created) console window, one could argue that this fits fairly
good with the description "no redirection will occur". 

If we would change this, so that the parents handles are always inherited,
then how would you specify that you want to attach the standard handles to
the new console window? 

For best flexibility, the API should allow both cases: Both inherit all
handles from the parent as well as attaching all standard handles to the
new console window. As you point out, the current API allows this. So why
change this?

One thing that's clearly an bug is the second part of the documentation:

"With None, no redirection will occur; the child's file handles will be
inherited from the
parent"

This is currently only true on UNIX. If we should keep the current
behaviour, at least the comment needs to be fixed. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1227748&group_id=5470