Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: gentoo_eshoes@tutanota.com
Newsgroups: gnu.bash.bug
Subject: Re: looking for consistent C-c trap behavior
Date: Fri, 17 Apr 2020 22:18:29 +0200 (CEST)
Lines: 34
Approved: bug-bash@gnu.org
Message-ID: <mailman.542.1587154715.3066.bug-bash@gnu.org>
References: <M58iOBd--3-2@tutanota.com> <CAOSMAuuow0=Q7dzYyw3DnYduX79+Cqcc1jyb6q3KZK+z3ofzpg@mail.gmail.com> <M58lP4X--3-2@tutanota.com> <M58mif3--3-2@tutanota.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: bug-bash <bug-bash@gnu.org>
To: Eduardo Bustamante <dualbus@gmail.com>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <M58lP4X--3-2@tutanota.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:16158




Apr 17, 2020, 22:14 by gentoo_eshoes@tutanota.com:

>
>
>
> 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...
>
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.