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: Re: Change in SIGTERM behaviour in bash 4.3 when using readline
Date: Wed, 4 Mar 2020 19:29:18 +0000
Lines: 17
Approved: bug-bash@gnu.org
Message-ID: <mailman.2049.1583350164.2412.bug-bash@gnu.org>
References: <20200304181824.GA394387@chrisdown.name> <20200304192918.GB394387@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
In-Reply-To: <20200304181824.GA394387@chrisdown.name>
Precedence: list
Xref: csiph.com gnu.bash.bug:15988

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...