New submission from Dave Malcolm <dmalc...@redhat.com>: 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
Arguably this is a bug; if the subprocess could crash, the user currently has to check for it by both monitoring the returncode _and_ catching OSError (then examining for this specific errno), which seems ugly to me. I'm attaching a patch for subprocess which handles this case, masking the OSError within the Popen implementation, so that you have to test for it within the returncode, in one place, rather than wrap every call with a try/except. 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. This was originally filed downstream within the Red Hat bugzilla instance as: https://bugzilla.redhat.com/show_bug.cgi?id=667431 The handler part of the patch is based on a patch attached there by Federico Simoncelli; I don't know if he has signed a PSF contributor agreement, however the size of the patch is sufficiently small that I suspect it's not copyrightable, and I've somewhat rewritten it since; I wrote the unit test. ---------- components: Library (Lib) files: py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch keywords: patch messages: 126643 nosy: dmalcolm priority: normal severity: normal stage: patch review status: open title: "subprocess" can raise OSError (EPIPE) when communicating with short-lived processes versions: Python 3.3 Added file: http://bugs.python.org/file20469/py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10963> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com