On 2022-12-18 08:27:31 +0700, Robert Elz wrote: > | https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html just > | says that if the shell is interactive, SIGQUIT shall be ignored. > > That just means that the shell doesn't exit with a core dump when the > signal is generated (however it is generated, including via kill(2)). > > What happens depends upon the terminal settings, and how the shell > chooses to implement command line editing (which is specified to exist, > at least for vi mode - others are allowed as alternatives - but isn't > specified how it works). > > If the shell isn't doing command line editing, the effects of the > quit character on the terminal input buffer still occur (anything > pending is flushed), if it is, then it all depend what (if anything) > the Ctrl-\ (or other char that might be set as the quit char in termios) > is defined to work in that editor - one can bind it to do almost > anything in most shells (typing the character doesn't necessarily > generate a SIGQUIT).
Well, so it is not forbidden to bind it to "exit with a core dump" (e.g. abort()), which is what a SIGQUIT does by default. :-) Then the requirement from the standard is a bit strange. One may still say that it is useful for a SIGQUIT sent by some process, but I have the impression that this is an unusual case and that the standard was more targeting a SIGQUIT generated by the QUIT character. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
