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

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy: +benjamin.peterson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Jakub Wilk]

Changes by Jakub Wilk jw...@jwilk.net:


--
nosy: +jwilk

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Matt Joiner]

Changes by Matt Joiner anacro...@gmail.com:


--
nosy: +anacrolix

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

Changes by Barry A. Warsaw ba...@python.org:


--
nosy: +barry

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mitar]

Mitar mmi...@gmail.com 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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gregory P. Smith]

Gregory P. Smith g...@krypto.org 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 would need to be able to return it so that software wanting to 
temporarily handle its own sigpipes could restore that behavior afterwards.

--
resolution:  - fixed
status: open - closed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Robert Cronk]

Changes by Robert Cronk cron...@gmail.com:


--
nosy: +rcronk

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Florent Xicluna]

Florent Xicluna florent.xicl...@gmail.com added the comment:

Fixed an oversight on the switch None == -1 which prevents compilation on some 
buildbot. See r78961.

--
nosy: +flox

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gregory P. Smith]

Gregory P. Smith g...@krypto.org 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 rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr 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 patch, you don't need to import `signal` again: it's already 
imported at the top level.

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Colin Watson]

Colin Watson cjwat...@users.sourceforge.net added the comment:

Is there anything more I can do to move this along? Thanks.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Andreas Kloeckner]

Changes by Andreas Kloeckner inf...@tiker.net:


--
nosy: +inducer

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

Hmm.  Looks like the patch is missing a unit test for the new feature.

--
stage: patch review - test needed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1652
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Colin Watson]

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]
http://bugs.python.org/issue1652
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

Georg Brandl [EMAIL PROTECTED] added the comment:

Martin, what do you think?

--
assignee:  - loewis

__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1652
__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Martin v. Löwis]

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. Colin, if that wasn't your intention, please speak up.

--
assignee: loewis - 
priority: high - normal
versions: +Python 2.6 -Python 2.5

__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1652
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

Georg Brandl added the comment:

Martin, what do you think?

--
assignee:  - loewis
nosy: +loewis

__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1652
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Colin Watson]

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 for Python to move to behaviour equivalent to
restore_sigpipe=True in the next release, but I would rather that it
gained restore_sigpipe with the wrong default than that it didn't gain
it at all.

__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1652
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Georg Brandl]

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]
http://bugs.python.org/issue1652
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Colin Watson]

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 SIGPIPE set to the
default action, since that's what will happen if they're started from a
normal shell. If this is not the case, then rather than taking SIGPIPE
when a write fails due to the reading end of a pipe having been closed,
write will return EPIPE and it's up to the process to check that. Many
programs are lazy and fail to check for write errors, but in the
specific case of pipe closure they are fine when invoked from a normal
shell because they rely on taking the signal. Even correctly written
programs that diligently check for write errors will typically produce
different (and confusing) output when SIGPIPE is ignored. For instance,
an example only very slightly adapted from one in the subprocess
documentation:

  $ dd if=/dev/zero of=bigfile bs=1024 seek=1 count=1
  1+0 records in
  1+0 records out
  1024 bytes (1.0 kB) copied, 0.000176709 seconds, 5.8 MB/s
  $ cat bigfile | head -n0
  $ cat t.py
  from subprocess import Popen, PIPE
  p1 = Popen([cat, bigfile], stdout=PIPE)
  p2 = Popen([head, -n0], stdin=p1.stdout, stdout=PIPE)
  output = p2.communicate()[0]
  $ python t.py
  cat: write error: Broken pipe

In some cases this problem can be much more significant. For instance,
it is very common for shell scripts to rely on SIGPIPE's default action
in order to behave correctly. A year or two ago I ran into this in OS
installer code I was writing in Python, which called some underlying
utility code in shell and C to deal with disk partitioning. In the event
that the Python code failed to handle an exception, the shell script
being run in a subprocess would spiral out of control rather than
cleanly exiting at the first sign of trouble. This actually caused
massive data loss on several testers' systems and required a quick
release to fix
(https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/40464 and
https://wiki.ubuntu.com/DapperBeta/PartitionTableCorruption). Now
obviously this was ultimately my fault for failing to catch the
exceptional condition in testing, but this misdesign in Python and the
lack of any documentation of this gotcha really didn't help at the time.
For the record, the fix was to call this in a preexec_fn:

  signal.signal(signal.SIGPIPE, signal.SIG_DFL)

This is an area of Unix that's very easy to get wrong. I've written my
own subprocess handling library in C for another project, and I still
found it non-trivial to track this down when it bit me. Since it
essentially arises due to an implementation detail of the Python
language, I think it should also be Python's responsibility to fix it up
when subprocesses are involved.

There are many ways to invoke subprocesses in Python, but the new,
all-singing, all-dancing one is of course the subprocess module. I think
it would be sufficient for that to do the right thing, or at least have
an option to do so, and it's certainly the easiest place to add the
option. I'm attaching a suggested patch which adds a restore_sigpipe
option and documents it in what seem to be all the relevant places.

Note that nearly all the examples end up with restore_sigpipe enabled.
In some future release of Python, I think this should be the default.
I'm not entirely familiar with migration plan processes in Python; how
should this be done?

--
components: Library (Lib)
files: subprocess-sigpipe.patch
messages: 58750
nosy: cjwatson
severity: normal
status: open
title: subprocess should have an option to restore SIGPIPE to default action
versions: Python 2.5
Added file: http://bugs.python.org/file8986/subprocess-sigpipe.patch

__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1652
__Index: Doc/library/subprocess.rst
===
--- Doc/library/subprocess.rst	(revision 59547)
+++ Doc/library/subprocess.rst	(working copy)
@@ -30,7 +30,7 @@
 This module defines one class called :class:`Popen`:
 
 
-.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0)
+.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_sigpipe=False)
 
Arguments are:
 
@@ -112,6 +112,12 @@
underlying CreateProcess() function.  They can specify things such as appearance
of the main window and priority for the new process.  (Windows only)
 
+   On UNIX: If *restore_sigpipe* is true, :const:`SIGPIPE` will be restored
+   to