Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!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:14:10 +0200 (CEST)
Lines: 54
Approved: bug-bash@gnu.org
Message-ID: <mailman.540.1587154456.3066.bug-bash@gnu.org>
References: <M58iOBd--3-2@tutanota.com> <CAOSMAuuow0=Q7dzYyw3DnYduX79+Cqcc1jyb6q3KZK+z3ofzpg@mail.gmail.com> <M58lP4X--3-2@tutanota.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_71342_1741311976.1587154450506"
Cc: bug-bash <bug-bash@gnu.org>
To: Eduardo Bustamante <dualbus@gmail.com>
Envelope-to: bug-bash@gnu.org
In-Reply-To: <CAOSMAuuow0=Q7dzYyw3DnYduX79+Cqcc1jyb6q3KZK+z3ofzpg@mail.gmail.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:16156

------=_Part_71342_1741311976.1587154450506
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit




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

------=_Part_71342_1741311976.1587154450506
Content-Type: application/octet-stream; name=sigintread.bash
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=sigintread.bash

IyEvYmluL2Jhc2gKCiN0cmFwIFNJR0lOVCB3b24ndCBicmVhayBmcm9tIGJ1aWx0aW4gcmVhZAoK
aW50ZXJydXB0ZWQoKSB7Cglsb2NhbCBlYz0iJD8iCgl0cmFwIC0gU0lHSU5UICAjdGhpcyByZXN0
b3JlcyBwcmV2LiBiZWhhdmlvdXIsIHNvIG5vdyBhbm90aGVyIEMtYyB3aWxsIHN0b3AgJ3JlYWQg
LXJwJwogIGVjaG8gImludGVycnVwdGVkIHNlZXMgZXhpdCBjb2RlICckZWMnIgogICNleGl0ICIk
ZWMiICAjdGhpcyBpcyBuZWVkZWQgT05MWSBmb3Igd2hlbiAnc2xlZXAnIGlzIHVzZWQgYW5kIGlu
dGVycnVwdGVkLCBvciBlbHNlIGl0IHdpbGwgY29udGludWUgcnVubmluZyBhbmQgaGl0ICdOb3Jt
YWwgZXhpdCcsIGlmIHVzZWQgd2l0aCAncmVhZCcgdGhlbiBpdCB3aWxsIGV4aXQgd2l0aG91dCBi
cmVha2luZyAncmVhZCcgdGh1cyBleGl0IGNvZGUgaXMgMCBpbnN0ZWFkIG9mIDEzMCAoMTI4KzIg
YWthIFNJR0lOVD09MikKfQoKdHJhcCBpbnRlcnJ1cHRlZCBTSUdJTlQKYnVpbHRpbiByZWFkIC1y
cCAiUHJlc3MgQy1jIGhlcmUuLi4iICAjY2FuIHVzZSAnc2xlZXAgMTAwJyBpbnN0ZWFkIG9mIHRo
aXMgJ3JlYWQuLi4nIGhlcmUsIGZvciB0ZXN0aW5nIGhvdyB0aGUgYmVoYXZpb3VyIGlzIGRpZmZl
cmVudCB3aXRoIGFuIGV4dGVybmFsIGNvbW1hbmQgaW5zdGVhZCBvZiBhIGJ1aWx0aW4gb25lLgpz
bGVlcCAxMDAKZWM9IiQ/IgplY2hvCmVjaG8gIk5vcm1hbCBleGl0IHNlZXMgZWM9JGVjIgpleGl0
ICIkZWMiCg==
------=_Part_71342_1741311976.1587154450506--