[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Ross Lagerwall added the comment: I'd argue that this is not a feature request but a bug. I did some testing of this issue and the problem is that EPIPE is only generated sometimes depending on the time the process takes to finish, the size of the data sent, the underlying mechanism used (sel

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Ross Lagerwall added the comment: Marked #6457 as a duplicate. See #6457 for more discussion. -- nosy: +Yaniv.Aknin, amaury.forgeotdarc, dwalczak, mcrute ___ Python tracker ___

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Antoine Pitrou added the comment: > I think it's best to remove all this inconsistency and fix it so that > EPIPE is never generated and then backport it to 2.7, 3.1, 3.2. > > Attached is a patch which fixes it for poll, select, windows and adds > two tests. The patch looks good to me. --

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Roundup Robot added the comment: New changeset c10d55c51d81 by Ross Lagerwall in branch '2.7': Issue #10963: Ensure that subprocess.communicate() never raises EPIPE. http://hg.python.org/cpython/rev/c10d55c51d81 New changeset 158495d49f58 by Ross Lagerwall in branch '3.1': Issue #10963: Ensure

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Ross Lagerwall added the comment: Committed, thanks. -- assignee: -> rosslagerwall resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: feature request -> behavior ___ Python tracker

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

New submission from Dave Malcolm : If we start a short-lived process which finishes before we begin communicating with it (e.g. by crashing), we can receive a SIGPIPE due to the receiving process no longer existing. This becomes an EPIPE, which becomes an: OSError: [Errno 32] Broken pipe Ar

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Antoine Pitrou added the comment: > It could be argued that this is incorrect, as it masks under-reads of > stdin by the subprocess. However I believe a sanely-written subprocess > ought to indicate success/failure back with its return code. It seems quite orthogonal. The subprocess could hav

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Federico Simoncelli added the comment: I agree they are orthogonal. The problem is that Popen.communicate doesn't support a way to ignore the exception and keep reading from stdout and sterr until the process dies. When the child closes the stdin its (error/debug/info) messages on stout/sterr

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Antoine Pitrou added the comment: You are right, this is suboptimal. It would also be a behaviour change from currently, but it seems beneficial. -- nosy: +gregory.p.smith type: -> feature request ___ Python tracker

[issue10963] "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http: