On Fri, Apr 17, 2020 at 1:09 PM Greg Wooledge <wool...@eeg.ccf.org> wrote: > > On Fri, Apr 17, 2020 at 01:02:20PM -0700, Eduardo Bustamante wrote: > > On Fri, Apr 17, 2020 at 12:59 PM gentoo_eshoes--- via Bug reports for > > the GNU Bourne Again SHell <bug-bash@gnu.org> wrote: > > > > > > I've noticed that if I trap SIGINT in a bash script, the behavior when > > > encountering C-c depends on whether an external command (eg. 'sleep 100') > > > or a builtin command (like 'read -p') was encountered. > > > > > > I attach an example script which requires me to press C-c twice to > > > interrupt the builtin 'read -p' command, and it only works because I'm > > > restoring the trap via 'trap - SIGINT' the first time. > > > > > > My goal is to have C-c interrupt and use that exit code (130 most likely) > > > to exit with from script, regardless or whether or not the interrupted > > > command in the script was an internal or external one. > > > > > > How to do? > > > > I recommend reading: https://www.cons.org/cracauer/sigint.html > > > > The problem is that the signal is sent to the foreground process. When > > "sleep" is running, it's the sleep command that receives the signal > > and decides what to do with it. Not bash. > > That's not quite right. When you press ^C in a terminal, SIGINT is sent > to *all* of the processes in the "foreground" process group -- both sleep > and bash, in the case you're discussing.
Oops. Apologies for giving out incorrect information. And thank you for taking your time to explain it properly.
