bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looking for consistent C-c trap behavior


From: gentoo_eshoes
Subject: Re: looking for consistent C-c trap behavior
Date: Fri, 17 Apr 2020 22:14:10 +0200 (CEST)



Apr 17, 2020, 22:02 by dualbus@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...

aww man, I forgot to attach it, no wonder you misunderstood...
my apologies

Attachment: sigintread.bash
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]