GNU bug report logs - #58440
27.2; Exit Code on SIGINT is Zero, But shouldn't Be

Previous Next

Package: emacs;

Reported by: Morten Welinder <mwelinder <at> gmail.com>

Date: Tue, 11 Oct 2022 13:50:02 UTC

Severity: minor

Found in version 27.2

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
Cc: 58440 <at> debbugs.gnu.org, Morten Welinder <mwelinder <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be
Date: Wed, 12 Oct 2022 17:46:55 +0200
Mattias EngdegÄrd <mattias.engdegard <at> gmail.com> writes:

>> It does seem like a bug -- I'd expect a non-zero exit code in this case. 
>
> It's by design, more or less: see handle_interrupt_signal in
> keyboard.c. Whether that design is desired or not is a different
> matter.
>
> (C-g should probably not generate a signal in the first place; it
> creates more problems than it solves.)

Hm, sounds like it...

But looking at the code:

----
/* The SIGINT handler.

   If we have a frame on the controlling tty, we assume that the
   SIGINT was generated by C-g, so we call handle_interrupt.
   Otherwise, tell maybe_quit to kill Emacs.  */

static void
handle_interrupt_signal (int sig)
----

But if I 

./src/emacs -Q && echo 'OK'

and then `C-g', that has no effect, but we still hit this logic?  And
even if:

(./src/emacs -Q && echo 'OK' )&

where the Emacs definitely isn't attached to the tty, then `C-g' in the
terminal can't have any effect (and doesn't).  But we still end up in
this code?

That seems like a bug, possibly?





This bug report was last modified 2 years and 308 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.