Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #15988
| From | Chris Down <chris@chrisdown.name> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: Change in SIGTERM behaviour in bash 4.3 when using readline |
| Date | 2020-03-04 19:29 +0000 |
| Message-ID | <mailman.2049.1583350164.2412.bug-bash@gnu.org> (permalink) |
| References | <20200304181824.GA394387@chrisdown.name> <20200304192918.GB394387@chrisdown.name> |
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...
Back to gnu.bash.bug | Previous | Next | Find similar
Re: Change in SIGTERM behaviour in bash 4.3 when using readline Chris Down <chris@chrisdown.name> - 2020-03-04 19:29 +0000
csiph-web