bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Change in SIGTERM behaviour in bash 4.3 when using readline


From: Chet Ramey
Subject: Re: Change in SIGTERM behaviour in bash 4.3 when using readline
Date: Wed, 4 Mar 2020 16:26:32 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 3/4/20 2:29 PM, Chris Down wrote:
> Ah, it's been a while since I did this and I forgot about the granularity
> of the devel branch :-)
> 
> There it bisects to 73a146bec7f75da9f78f6d54329c980b75a2318d ("commit
> bash-20130215 snapshot"). I'm pretty sure it's related to this change to
> add the signal handler inside initialize_shell_signals, which sets a new
> handler if SIGTERM isn't SIG_HARD_IGNORE.
> 
> If I read the code correctly, in that case we will resume due to
> SA_RESTART, but bubbling up readline() will now return 0, which will be
> passed to yy_readline_get(), which returns EOF if current_readline_line is
> 0, so the shell closes.
> 
> I'm not quite sure how best to handle this, maybe setting SIG_IGN as the
> default signal handler for interactive shells if there's nothing to
> inherit? This is one of those cases where SA_RESTART doesn't quite mimic
> SIG_IGN...

It has the same effect when called, but the key change is that readline,
noticing that SIGTERM is not ignored when it starts, installs its own
signal handler, which sets _rl_caught_signal accordingly. Then SIGTERM
interrupts the read, returns READERR/EOF, and we go from there (readline
only installs its SIGWINCH handler with SA_RESTART, since that is the right
thing for most applications).

Another consideration for treating SIGTERM and SIGHUP the same inside
the readline input code was the existence of terminal handlers that sent
SIGTERM when a user pressed the `close' button. If you don't return an
error in that case, readline just spins in the background.

If someone can guarantee to me that there are no remaining terminal
emulators that send SIGTERM in that case (that is, everyone sends SIGHUP
and possibly revokes read access from the process read size of the pty),
we can remove SIGTERM's special handling inside readline's input code and
let it be handled like other signals. Terminal emulators have evolved
considerably since then, so it might be possible to guarantee this.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]