[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: looking for consistent C-c trap behavior
From: |
Chet Ramey |
Subject: |
Re: looking for consistent C-c trap behavior |
Date: |
Sun, 19 Apr 2020 15:16:15 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
On 4/18/20 5:41 PM, gentoo_eshoes@tutanota.com wrote:
> can confirm that indeed `bash --posix` does interrupt the 'read -p' on first
> C-c, however, the inside-trap seen exit code is 0, but if the trap doesn't
> `exit` itself, then the exit code after the 'read -p' is seen correctly as
> 130, ie.
> $ ./sigintread.bash
> Press C-c here...^Cinterrupted sees exit code '0'
>
> Normal exit sees ec=130
>
> Would it be possible to somehow get 130 even inside the trap function?
>
> this would then be equivalent with interrupting 'sleep' for example:
> $ ./sigintread.bash
> ^Cinterrupted sees exit code '130'
>
> Normal exit sees ec=130
This is a reasonable idea for posix mode, since the trap action is run
after the read command returns.
> On another note, I naively tried to patch out the POSIX requirement, for my
> own/local_use puposes but had no effect:
This (from bashline.c) is for readline support. The `read -e' comment is
true.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
- Re: looking for consistent C-c trap behavior, (continued)