Debian Bug report logs - #683671
dash doesn't ignore SIGINT when running a command that traps SIGINT, should implement WCE

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: dash doesn't ignore SIGINT when running an interactive command

Date: Thu, 2 Aug 2012 19:06:19 +0200

Package: dash
Version: 0.5.7-3
Severity: grave
Justification: causes non-serious data loss

When running an interactive command, dash doesn't ignore SIGINT
and SIGQUIT.

For instance, here's what I get with Emacs 24 (not a previous
version, since previously, Emacs had its own progress group,
so that the bug wasn't visible), by typing Ctrl-G Ctrl-X Ctrl-C
in Emacs:

$ bash -c "emacs -Q -nw; echo foo"; echo bar
foo
bar
$ dash -c "emacs -Q -nw; echo foo"; echo bar

$ echo $?
130
$ 

The main problem is that dash is generally used as /bin/sh, thus
by the system() command (or equivalent). So, typing Ctrl-G in an
Emacs running in a terminal has the effect to make the sh shell
fail, without any possible workaround. This affects applications
that run an editor such as Subversion (svn command) and Mutt.

For instance, with svn:

$ SVN_EDITOR=emacs svn ci
svn: E200012: Commit failed (details follow):
svn: E200012: system('emacs svn-commit.tmp') returned 2
svn: E200012: Your commit message was left in a temporary file:
svn: E200012:    '/home/vinc17/wd/db/svn-commit.tmp'

zsh: interrupt  SVN_EDITOR=emacs svnwrapper ci

According to Andreas Schwab[*], this is a bug in dash. And indeed,
the system(3) man page says:

      system()  executes a command specified in command by calling
      /bin/sh -c command, and returns after the command  has  been
      completed.  During execution of the command, SIGCHLD will be
      blocked, and SIGINT and SIGQUIT will be ignored.

[*] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886#17

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dash depends on:
ii  debianutils  4.3.3
ii  dpkg         1.16.8
ii  libc6        2.13-35

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Message #10 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: 683671@bugs.debian.org

Subject: Re: dash doesn't ignore SIGINT when running an interactive command

Date: Thu, 2 Aug 2012 11:03:11 -0700

severity 683671 serious
# not Debian-specific
tags 683671 + upstream moreinfo
quit

Hi Vincent,

Vincent Lefevre wrote:

> Severity: grave
> Justification: causes non-serious data loss

Can you explain that more precisely?  At first glance it seems like an
ordinary important bug.

[...]
> [*] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886#17

Thanks for the pointer.

http://unix.org/2008edition/ tells me:

  When a command is in an asynchronous list, it shall inherit from the
  shell a signal action of ignored (SIG_IGN) for the SIGQUIT and
  SIGINT signals, and may inherit a signal mask in which SIGQUIT and
  SIGINT are blocked. Otherwise, the signal actions and signal mask
  inherited by the command shall be the same as those inherited by the
  shell from its parent unless a signal action is modified by the trap
  special built-in (see trap )

In 'sh -c "emacs -nw"', the emacs command is not in an asynchronous
list, so I would suspect that emacs is supposed to inherit the same
signal actions as the shell inherited.

How about this patch (which at least gets rid of a mysterious code
artifact)?

Curious,
Jonathan

diff --git a/src/trap.c b/src/trap.c
index 17316c9..1fa835b 100644
--- a/src/trap.c
+++ b/src/trap.c
@@ -347,7 +347,7 @@ setinteractive(int on)
 {
 	static int is_interactive;
 
-	if (++on == is_interactive)
+	if (on == is_interactive)
 		return;
 	is_interactive = on;
 	setsignal(SIGINT);

Message #19 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 683671@bugs.debian.org

Subject: Re: dash doesn't ignore SIGINT when running an interactive command

Date: Tue, 7 Aug 2012 14:40:19 +0200

Hi Jonathan,

On 2012-08-02 11:03:11 -0700, Jonathan Nieder wrote:
> Vincent Lefevre wrote:
> 
> > Severity: grave
> > Justification: causes non-serious data loss
> 
> Can you explain that more precisely?  At first glance it seems like an
> ordinary important bug.

Emacs is often called by other programs, and possibly from a /bin/sh
script, with postprocessing. Here's a simple example:

#!/bin/sh
trap 'true' INT
sh -c 'emacs -nw tmpfile; mv tmpfile newfile'
rm -f tmpfile
cat newfile
rm -f newfile

If Ctrl-G is typed in Emacs, the data are lost. Even though a
correction could be done on such a simple example, in real
applications, this is less obvious. And how do we do the difference
between (1) a real SIGINT from Ctrl-C, meaning that the user is no
longer interested in the data and clean-up can be done, and (2) a
SIGINT coming from a bug, meaning that temporary files should be
left on the disk and the user should guess where his data are and
what they mean?

> http://unix.org/2008edition/ tells me:
> 
>   When a command is in an asynchronous list, it shall inherit from the
>   shell a signal action of ignored (SIG_IGN) for the SIGQUIT and
>   SIGINT signals, and may inherit a signal mask in which SIGQUIT and
>   SIGINT are blocked. Otherwise, the signal actions and signal mask
>   inherited by the command shall be the same as those inherited by the
>   shell from its parent unless a signal action is modified by the trap
>   special built-in (see trap )

This paragraph is about signals inherited by the command. Here the
question is what the shell should do with SIGINT/SIGQUIT signals it
receives while it is executing a command which is not killed by the
signal?

Not that how the command is affected by the signal is important.
See the difference between:

#!/bin/sh
trap 'true' INT
bash -c 'date > tmpfile; sleep 5; mv tmpfile newfile'
rm -f tmpfile
cat newfile
rm -f newfile

with Ctrl-C during the "sleep 5", and:

#!/bin/sh
trap 'true' INT
bash -c 'date > tmpfile; emacs -nw; mv tmpfile newfile'
rm -f tmpfile
cat newfile
rm -f newfile

with Ctrl-G in Emacs. You can also try:

#!/bin/sh
trap 'true' INT
bash -c 'date > tmpfile; gdb; mv tmpfile newfile'
rm -f tmpfile
cat newfile
rm -f newfile

with Ctrl-C in gdb.

If bash is replaced by dash, one always gets a failure, not just in
the first case.

Since there was a similar problem with zsh and GNU Emacs under
Mac OS X (and I really lost data several times, until I identified
the problem, but contrary to here, the problem was occurring with
all Emacs versions[*]), I now remember this page:

  http://www.cons.org/cracauer/sigint.html

It probably gives the answer of what should be done.

[*] http://www.zsh.org/mla/workers/2009/msg00926.html

> How about this patch (which at least gets rid of a mysterious code
> artifact)?

This is worse: Ctrl-G in emacs kills emacs!

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #26 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: 683671@bugs.debian.org

Subject: Re: dash doesn't ignore SIGINT when running an interactive command

Date: Tue, 7 Aug 2012 08:26:46 -0700

Vincent Lefevre wrote:
> On 2012-08-02 11:03:11 -0700, Jonathan Nieder wrote:

>> How about this patch (which at least gets rid of a mysterious code
>> artifact)?
>
> This is worse: Ctrl-G in emacs kills emacs!

Weird.  Why does system(3) claim it sets SIGINT to SIG_IGN, then?

Puzzled,
Jonathan

Message #31 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Jonathan Nieder <jrnieder@gmail.com>

Cc: 683671@bugs.debian.org

Subject: Re: dash doesn't ignore SIGINT when running an interactive command

Date: Tue, 7 Aug 2012 18:47:15 +0200

On 2012-08-07 08:26:46 -0700, Jonathan Nieder wrote:
> Vincent Lefevre wrote:
> > On 2012-08-02 11:03:11 -0700, Jonathan Nieder wrote:
> 
> >> How about this patch (which at least gets rid of a mysterious code
> >> artifact)?
> >
> > This is worse: Ctrl-G in emacs kills emacs!
> 
> Weird.  Why does system(3) claim it sets SIGINT to SIG_IGN, then?

Well, this is from POSIX:

  http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html

It is said:

  The system() function shall behave as if a child process were
  created using fork(), and the child process invoked the sh utility
  using execl() as follows:

    execl(<shell path>, "sh", "-c", command, (char *)0);

  where <shell path> is an unspecified pathname for the sh utility. It
  is unspecified whether the handlers registered with pthread_atfork()
  are called as part of the creation of the child process.

  The system() function shall ignore the SIGINT and SIGQUIT signals,
  and shall block the SIGCHLD signal, while waiting for the command to
  terminate. If this might cause the application to miss a signal that
  would have killed it, then the application should examine the return
  value from system() and take whatever action is appropriate to the
  application if the command terminated due to receipt of a signal.

The rationale makes it clear about which process(es) shall ignore
these signals:

  Ignoring SIGINT and SIGQUIT in the parent process prevents
  coordination problems (two processes reading from the same terminal,
  for example) when the executed command ignores or catches one of the
  signals.

and from the example implementation, one can see that the previous
actions are restored in the child, just before executing /bin/sh.

This contradicts the glibc manual, which doesn't claim to do anything
concerning signals in the system() implementation (and in some other
discussion, it was said that glibc does only what is written):

 -- Function: int system (const char *COMMAND)
     This function executes COMMAND as a shell command.  In the GNU C
     library, it always uses the default shell `sh' to run the command.
     In particular, it searches the directories in `PATH' to find
     programs to execute.  The return value is `-1' if it wasn't
     possible to create the shell process, and otherwise is the status
     of the shell process.  *Note Process Completion::, for details on
     how this status code can be interpreted.

     If the COMMAND argument is a null pointer, a return value of zero
     indicates that no command processor is available.

     This function is a cancellation point in multi-threaded programs.
     This is a problem if the thread allocates some resources (like
     memory, file descriptors, semaphores or whatever) at the time
     `system' is called.  If the thread gets canceled these resources
     stay allocated until the program ends.  To avoid this calls to
     `system' should be protected using cancellation handlers.

     The `system' function is declared in the header file `stdlib.h'.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #36 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Vincent Lefevre <vincent@vinc17.net>

Cc: 683671@bugs.debian.org

Subject: Re: dash doesn't ignore SIGINT when running an interactive command

Date: Wed, 8 Aug 2012 01:38:58 -0700

Vincent Lefevre wrote:

>   Ignoring SIGINT and SIGQUIT in the parent process prevents
>   coordination problems (two processes reading from the same terminal,
>   for example) when the executed command ignores or catches one of the
>   signals.
>
> and from the example implementation, one can see that the previous
> actions are restored in the child, just before executing /bin/sh.

Ah, I should have remembered.  That's the right behavior for system(),
and it's what glibc does.  (I'm afraid I have no interest in fixing
the glibc manual, since its copyright holders have chosen to use an
unpleasant license and stick to it and there is better documentation
available elsewhere.)

Thanks,
Jonathan

Message #41 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: Vincent Lefevre <vincent@vinc17.net>, 683671@bugs.debian.org

Cc: Jonathan Nieder <jrnieder@gmail.com>

Subject: Re: Bug#683671: dash doesn't ignore SIGINT when running an interactive command

Date: Tue, 28 Aug 2012 11:05:45 +0000

On Thu, Aug 02, 2012 at 07:06:19PM +0200, Vincent Lefevre wrote:
> Package: dash
> Version: 0.5.7-3
> Severity: grave
> Justification: causes non-serious data loss
> 
> When running an interactive command, dash doesn't ignore SIGINT
> and SIGQUIT.
> 
> For instance, here's what I get with Emacs 24 (not a previous
> version, since previously, Emacs had its own progress group,
> so that the bug wasn't visible), by typing Ctrl-G Ctrl-X Ctrl-C
> in Emacs:
> 
> $ bash -c "emacs -Q -nw; echo foo"; echo bar
> foo
> bar
> $ dash -c "emacs -Q -nw; echo foo"; echo bar
> 
> $ echo $?
> 130
> $ 

> According to Andreas Schwab[*], this is a bug in dash. And indeed,
> the system(3) man page says:
> 
>       system()  executes a command specified in command by calling
>       /bin/sh -c command, and returns after the command  has  been
>       completed.  During execution of the command, SIGCHLD will be
>       blocked, and SIGINT and SIGQUIT will be ignored.
> 
> [*] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886#17

Hi,

this bug log now suggests that zsh is in the same boat and the bug
possibly lies within emacs.  Do you still think it's a release-critical
bug in dash?

Thanks, Gerrit.

Message #44 received at 683671-submitter@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@dbnbgs.smarden.org>

To: 683671-submitter@bugs.debian.org

Subject: [MAILER-DAEMON@a.mx.smarden.org: failure notice]

Date: Tue, 28 Aug 2012 11:22:39 +0000

spamcop is wrong.


----- Forwarded message from MAILER-DAEMON@a.mx.smarden.org -----

Date: 28 Aug 2012 11:12:28 -0000
From: MAILER-DAEMON@a.mx.smarden.org
Subject: failure notice

Hi. This is the qmail-send program at a.mx.smarden.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<vincent@vinc17.net>:
92.243.22.117 does not like recipient.
Remote host said: 554 5.7.1 Service unavailable; Client host [176.74.58.109] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?176.74.58.109
Giving up on 92.243.22.117.

--- Below this line is a copy of the message.

Received: (qmail 3983 invoked by uid 1000); 28 Aug 2012 11:05:45 -0000
Message-ID: <20120828110545.3982.qmail@818822b293fcc9.315fe32.mid.smarden.org>
Date: Tue, 28 Aug 2012 11:05:45 +0000
From: Gerrit Pape <pape@smarden.org>
To: Vincent Lefevre <vincent@vinc17.net>, 683671@bugs.debian.org
Cc: Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Bug#683671: dash doesn't ignore SIGINT when running an
 interactive command
Reply-To: Vincent Lefevre <vincent@vinc17.net>, 683671@bugs.debian.org,
  Jonathan Nieder <jrnieder@gmail.com>
References: <20120802170618.GA18343@ypig.lip.ens-lyon.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20120802170618.GA18343@ypig.lip.ens-lyon.fr>

On Thu, Aug 02, 2012 at 07:06:19PM +0200, Vincent Lefevre wrote:
> Package: dash
> Version: 0.5.7-3
> Severity: grave
> Justification: causes non-serious data loss
> 
> When running an interactive command, dash doesn't ignore SIGINT
> and SIGQUIT.
> 
> For instance, here's what I get with Emacs 24 (not a previous
> version, since previously, Emacs had its own progress group,
> so that the bug wasn't visible), by typing Ctrl-G Ctrl-X Ctrl-C
> in Emacs:
> 
> $ bash -c "emacs -Q -nw; echo foo"; echo bar
> foo
> bar
> $ dash -c "emacs -Q -nw; echo foo"; echo bar
> 
> $ echo $?
> 130
> $ 

> According to Andreas Schwab[*], this is a bug in dash. And indeed,
> the system(3) man page says:
> 
>       system()  executes a command specified in command by calling
>       /bin/sh -c command, and returns after the command  has  been
>       completed.  During execution of the command, SIGCHLD will be
>       blocked, and SIGINT and SIGQUIT will be ignored.
> 
> [*] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886#17

Hi,

this bug log now suggests that zsh is in the same boat and the bug
possibly lies within emacs.  Do you still think it's a release-critical
bug in dash?

Thanks, Gerrit.

----- End forwarded message -----

Message #49 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: 683671@bugs.debian.org

Subject: Re: Bug#683671: dash doesn't ignore SIGINT when running an interactive command

Date: Tue, 28 Aug 2012 14:36:59 +0200

On 2012-08-28 11:05:45 +0000, Gerrit Pape wrote:
> this bug log now suggests that zsh is in the same boat and the bug
> possibly lies within emacs.

Well, contrary to dash, zsh is not meant to be a POSIX shell, and
cannot (must not) be used as /bin/sh (zsh has a sh emulation mode,
but it is not perfect, and its status is quite unclear). This is
one major point.

However I think that any application that uses the INTR character
for its own, internal purpose should put itself in its own process
group to avoid side effects. But if developers don't agree, the
problem must be dealt with in the shell. Note that

  http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html

(see "Application Usage" and "Rationale") suggests that it's up to
the callers (the system() implementation and, by extension, the sh
implementation) to do the necessary to ignore signals when need be.
The fact that dash implements WUE instead of IUE avoids the most
important problems mentioned at the above URL, though.

Moreover gdb has the same problem as Emacs, though problems are less
likely to appear in practice than with Emacs (an editor is much more
often called by system() than gdb).

> Do you still think it's a release-critical bug in dash?

I think that the current status may badly affect the usual use of
some applications like Emacs. The fact that there are, AFAIK, no
workarounds (except by not using dash, e.g. by changing the /bin/sh
symlink) makes me think that it should still be a RC bug.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #54 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

To: 683671@bugs.debian.org, 683671-submitter@bugs.debian.org

Subject: re: dash doesn't ignore SIGINT when running a command that traps SIGINT

Date: Tue, 30 Oct 2012 18:38:14 -0400

> I think that the current status may badly affect the usual use of
> some applications like Emacs. The fact that there are, AFAIK, no
> workarounds (except by not using dash, e.g. by changing the /bin/sh
> symlink) makes me think that it should still be a RC bug.

Would you mind if this were reassigned to release-notes?  It would say
something along the lines of "Dash is not yet ready as an interactive
shell, bash is currently the only recommended posix-compliant shell.
You will experience issues such as #683671 using dash interactively."

In the meantime, this should be reported to the upstream dash
developers so they can start working on a fix.

Best wishes,
Mike

Message #62 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Jonathan Nieder <jrnieder@gmail.com>

To: Michael Gilbert <mgilbert@debian.org>

Cc: 683671@bugs.debian.org, 683671-submitter@bugs.debian.org

Subject: Re: dash doesn't ignore SIGINT when running a command that traps SIGINT

Date: Tue, 30 Oct 2012 15:46:40 -0700

Michael Gilbert wrote:

>> I think that the current status may badly affect the usual use of
>> some applications like Emacs. The fact that there are, AFAIK, no
>> workarounds (except by not using dash, e.g. by changing the /bin/sh
>> symlink) makes me think that it should still be a RC bug.
>
> Would you mind if this were reassigned to release-notes?  It would say
> something along the lines of "Dash is not yet ready as an interactive
> shell, bash is currently the only recommended posix-compliant shell.

I think that's an overstatement.  Maybe "Dash in Debian is not intended
to be used as an interactive shell" could be accurate, though.

Please don't reassign this bug, but feel free to clone it and lower
the severity.

Thanks,
Jonathan

Message #70 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: Jonathan Nieder <jrnieder@gmail.com>, 683671@bugs.debian.org

Cc: Michael Gilbert <mgilbert@debian.org>

Subject: Re: Bug#683671: dash doesn't ignore SIGINT when running a command that traps SIGINT

Date: Wed, 31 Oct 2012 00:59:30 +0100

On 2012-10-30 15:46:40 -0700, Jonathan Nieder wrote:
> Michael Gilbert wrote:
> > Would you mind if this were reassigned to release-notes?  It would say
> > something along the lines of "Dash is not yet ready as an interactive
> > shell, bash is currently the only recommended posix-compliant shell.
> 
> I think that's an overstatement.  Maybe "Dash in Debian is not intended
> to be used as an interactive shell" could be accurate, though.

The word "interactive" is incorrect, because when the shell is used
to run some program (e.g. via C's system() function), it is not
interactive.

> Please don't reassign this bug, but feel free to clone it and lower
> the severity.

Yes, this is really a bug in dash IMHO, but Emacs is partly in fault
because the Ctrl-G will also send the signal in the other processes in
the same process group an Emacs (though this may not be very common).
The current situation is extremely annoying. :(

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #75 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Vincent Lefevre <vincent@vinc17.net>

To: 695219@bugs.debian.org, 683671@bugs.debian.org

Subject: reportbug incorrectly says "Report has not been sent yet" after SIGINT sent to process group

Date: Wed, 5 Dec 2012 17:34:29 +0100

[also sent to 683671@b.d.o since this concerns dash; for reportbug,
one should do a test with bash as /bin/sh to see whether reportbug
is really buggy or if this is just a consequence of the dash bug.]

On 2012-12-05 16:53:41 +0100, Vincent Lefevre wrote:
> I think I've found how to reproduce it. It occurs when:
>   * the editor for Mutt is Emacs 24,
>   * Emacs runs in the terminal (e.g. because X11 DISPLAY is not
>     available, but this can also be done with "emacs -nw"),
>   * I type Ctrl-G in Emacs.
> 
> A Ctrl-G in Emacs 24 has the effect to send a SIGINT to the whole
> process group (previous Emacs versions behave differently, and this
> problem was fixed in the Emacs trunk[*]) since Emacs changes the
> INTR character to Ctrl-G for internal use and doesn't put itself
> in its own process group. Mutt itself is not affected and I could
> check that it terminates normally, i.e. with a 0 exit status. So,
> I suppose that reportbug can't handle the SIGINT gracefully. Or
> it could be due to this dash bug:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671
> 
> since a ps shows that reportbug runs Mutt via "sh -c".
> 
> [*] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11886

I couldn't try because the Debian BTS doesn't have a test system
(due avoid creating a dummy bug report), but a Ctrl-C in Mutt
also sends a SIGINT to the whole process group (as expected),
even when one doesn't quit Mutt and Mutt terminates normally.
So, even if the problem is "fixed" (avoided) in Emacs, the real
problem still exists.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #80 received at 683671@bugs.debian.org (full text, mbox, reply):

From: Julien Cristau <jcristau@debian.org>

To: Jonathan Nieder <jrnieder@gmail.com>, 683671@bugs.debian.org

Cc: Vincent Lefevre <vincent@vinc17.net>

Subject: Re: Bug#683671: dash doesn't ignore SIGINT when running an interactive command

Date: Sat, 26 Jan 2013 12:42:02 +0000

[Message part 1 (text/plain, inline)]

Control: severity -1 important

On Thu, Aug  2, 2012 at 11:03:11 -0700, Jonathan Nieder wrote:

> severity 683671 serious

I don't think this should be a blocker for release.  Downgrading.

Cheers,
Julien

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.