Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Chris Down <chris@chrisdown.name>
Newsgroups: gnu.bash.bug
Subject: Change in SIGTERM behaviour in bash 4.3 when using readline
Date: Wed, 4 Mar 2020 18:18:24 +0000
Lines: 28
Approved: bug-bash@gnu.org
Message-ID: <mailman.2046.1583345912.2412.bug-bash@gnu.org>
References: <20200304181824.GA394387@chrisdown.name>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Content-Disposition: inline
Precedence: list
Xref: csiph.com gnu.bash.bug:15987

Hi there,

A question on Unix & Linux Stack Exchange[0] brought up the question of SIGTERM 
terminating interactive bash shells. This surprised me, and after bisecting I 
narrowed it down to commit ac50fbac ("Bash-4.3 distribution sources and 
documentation").

Going through the commit I see a significant number of changes, like the 
addition of setting/checking the sigterm_received atomic in a number of places, 
and the special handling of some signals (including SIGTERM) as part of 
deciding whether to call rl_signal_event_hook.

It seems this behaviour is related to readline, because it goes away if I run 
with --noediting.

Before I spend the time to look through the code to work out exactly which part 
of ac50fbac results in this behaviour, since it's fairly substantial, I want to 
double check -- was this an intentional change or not? I can't really tell from 
CHANGES or NEWS: they mention some of the compile-time options around SIGTERM 
and rl_signal_event_hook, but I can't really tell the intent when it comes to 
this behaviour in particular. Certainly it came as a surprise to me, at least.

Thanks,

Chris

0: https://unix.stackexchange.com/q/571123/10762