Re: looking for consistent C-c trap behavior

[gentoo_eshoes--- via Bug reports for the GNU Bourne Again SHell]

Apr 17, 2020, 22:14 by gentoo_esh...@tutanota.com:

>
>
>
> Apr 17, 2020, 22:02 by dual...@gmail.com:
>
>> 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.
>>
> ok but sleep is doing great - it's doing what I expect it to do and bash is 
> trapping it just fine, it's the builtin 'read' that's the problem...
>
ok to be fair, you didn't really misunderstand, you were saying that if 'sleep' 
decided to not exit on SIGINT, there's not much I could do about it with 
bash/trap, or if it is... it's in that doc. Thank you for linking it.