On 3/28/18 12:52 PM, Martin Schulte wrote: > Hello, > > I'm running bash under Debian Stretch: > > $ echo $BASH_VERSION > 4.4.12(1)-release > $ trap > $ echo $$ > 1100 > $ kill 1100 > $ > > => Looks fine for me > > Then I do a > > kill 1100 > > from another session and the bash above terminates. > > => Looks wrong for me
It's readline. The difference between your two cases is that in the second one, readline gets the signal, and it interrupts the read. Readline handles the signal, calls the bash signal handler (which does nothing but set a flag and return), and returns a read error. You really have to return the error so the signal gets handled properly -- all the signal handler is allowed to do is to set a flag, and that's all the readline and bash signal handlers do. The idea is that terminal emulators (at least in 2011) send SIGTERM or SIGHUP when you use the close button, and unless readline returns an error, you get processes looping on a stream of read(2) returning EINTR or EIO. There is a related discussion beginning at http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00054.html Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
