bug#58440: 27.2; Exit Code on SIGINT is Zero, But shouldn't Be

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 58440@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 12 Oct 2022 13:22:28 +0200
> 
> Morten Welinder <mwelinder@gmail.com> writes:
> 
> > 1. Create the following perl script named "ttt":
> 
> Or an easier way to reproduce the issue:
> 
> ./src/emacs -Q; echo $?
> 
> and then "kill -INT" the process and observe that it echoes "0".

What happens if you say

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

does it say OK when you kill Emacs with SIGINT?

> This issue is still present in Emacs 29.
> 
> It does seem like a bug -- I'd expect a non-zero exit code in this case.

I very much doubt that the above is the same problem: Morten didn't
involve Python without a good reason.

And I'm not sure we have anything to do with what Morten reports: how
do we know if Python or its 'system' call blocks some signals, or does
some other non-trivial stuff with them?  Likewise with xterm.

> (And...  I'm not sure where the action taken for the signal really is
> after poking at the
> 
>   maybe_fatal_sig (SIGINT);
> 
> code paths a few minutes.)

In a GUI session, AFAIU SIGINT is handled as a fatal signal, and
should cause Emacs to shut down and return with exit code of 1.  Are
you saying that you don't see that in a debugger?  (I don't have
access to a GNU/Linux system where I can run a GUI Emacs session.)

By contrast, in a TTY (a.k.a. "-nw") session, SIGINT causes a keyboard
quit (we reprogram the keyboard to raise SIGINT when the user preses
C-g), so Emacs should not exit at all if SIGINT is delivered to it.
And Ctrl-C doesn't cause SIGINT anyway.

So I'd appreciate if Morten could explain some more of what he thinks
is going on and why he thinks this is an Emacs problem to begin with.