[issue1652] subprocess should have an option to restore SIGPIPE to default action

Change by Gregory P. Smith : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Changes by Jakub Wilk : -- nosy: +jwilk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Gregory P. Smith added the comment: closing because it is too late to backport this to 2.7. It is available as a backport in http://code.google.com/p/python-subprocess32/. As for the idea of not using SIG_IGN and installing a default no-op handler, that is another approach. signal.getsignal

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Mitar added the comment: GHC Haskell compiler is currently opting for a different solution: installing an default empty handler which is cleared by exec automatically and signal handler is restored back to SIG_DFL: http://hackage.haskell.org/trac/ghc/ticket/4274 -- nosy: +mitar

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Changes by Robert Cronk : -- nosy: +rcronk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Florent Xicluna added the comment: Fixed an oversight on the switch None ==> -1 which prevents compilation on some buildbot. See r78961. -- nosy: +flox ___ Python tracker ___ __

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Gregory P. Smith added the comment: A restore_signals parameter was added in py3k r78946. I'm leaving this issue open as it needs backporting to 2.7. -- versions: -Python 3.2 ___ Python tracker __

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Antoine Pitrou added the comment: I think restore_sigpipe=True would be a reasonable default. As RDM says, adding an unit test would be better, but it may be difficult to do so (we probably can't spawn Python itself since it will change the default SIGPIPE handler at startup). Looking at the p

[issue1652] subprocess should have an option to restore SIGPIPE to default action

R. David Murray added the comment: Hmm. Looks like the patch is missing a unit test for the new feature. -- stage: patch review -> test needed ___ Python tracker ___ ___

[issue1652] subprocess should have an option to restore SIGPIPE to default action

R. David Murray added the comment: Find someone to review the patch and post their evaluation here. It doesn't have to be a committer, though that would be even better. -- nosy: +r.david.murray stage: -> patch review versions: +Python 2.7, Python 3.2 -Python 2.6 _

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Changes by Andreas Kloeckner : -- nosy: +inducer ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Colin Watson added the comment: Is there anything more I can do to move this along? Thanks. -- ___ Python tracker ___ ___ Python-bugs-

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Georg Brandl <[EMAIL PROTECTED]> added the comment: Martin, what do you think? -- assignee: -> loewis __ Tracker <[EMAIL PROTECTED]> __ ___ Pyt

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Colin Watson <[EMAIL PROTECTED]> added the comment: 2.6 is fine if that's what the release process dictates; I don't want it to be lost, that's all. __ Tracker <[EMAIL PROTECTED]> __ __

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Martin v. Löwis added the comment: The patch as it stands (subprocess-sigpipe.patch) definitely can't go into 2.5.x: it introduces a new feature. It's not clear to me whether Colin intended to target it for 2.5.x, as it is against the trunk. For the trunk, the patch is fine. Regargeting for 2.6

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Georg Brandl added the comment: Martin, what do you think? -- assignee: -> loewis nosy: +loewis __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bu

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Colin Watson added the comment: To be quite honest I can't think of any incompatibilities that wouldn't have the basic result of improving matters. I put the migration stuff in my bug report in case somebody else could, because I don't want the bug fix to stall on that. My preference would be fo

[issue1652] subprocess should have an option to restore SIGPIPE to default action

Georg Brandl added the comment: Raising priority. What incompatibilities could occur if SIGPIPE is restored by default? -- nosy: +georg.brandl priority: -> high severity: normal -> major type: -> behavior __ Tracker <[EMAIL PROTECTED]>

[issue1652] subprocess should have an option to restore SIGPIPE to default action

New submission from Colin Watson: On Unix, Python sets SIGPIPE to SIG_IGN on startup, because it prefers to check every write and raise an IOError exception rather than taking SIGPIPE. This is all well and good for Python itself. However, non-Python Unix subprocesses generally expect to have SIGP