On Mon, Oct 12, 2026 at 4:32 PM Chet Ramey <[email protected]> wrote:
> On 10/12/26 10:30 AM, Denys Vlasenko wrote: > > On Mon, Oct 12, 2026 at 4:09 PM Chet Ramey <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 10/11/26 10:33 AM, Denys Vlasenko via Bug reports for the GNU > Bourne > > Again SHell wrote: > > > > > Now the same but with SIGTERM: > > > > > > me@myhost>$ bash > > > me@myhost>$ export PS1='Prompt> '; trap 'echo T' term; (while > kill $ > > $; do > > > sleep 1; done) & > > > [1] 65964 > > > Prompt> > > > exit > > > me@myhost>$ bash: line 1: kill: (65904) - No such process > > > > > > without me pressing anything. Why did bash exit?! The trap does > not > > contain > > > any 'exit' commands! > > > > Readline treats SIGTERM as a fatal signal, like SIGHUP. This allows > it to > > exit the calling application if, for instance, the terminal emulator > > window in which it's running is closed. > > > > > > Well, SIGTERM has nothing to do with tty's closure, why does it > > do that *on SIGTERM*? > > Because terminal emulators send SIGTERM to the foreground process group > when you use the `close' button instead of exiting the running application. > I think they are likely just close a pty pair they created. The HUP is sent automatically by kernel. This happens even if a xterm or telnetd/sshd/whatever simply crashes and thus closes its pty pair implicitly.
