[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] trap not invoked after resuming read from trap
From: |
Chet Ramey |
Subject: |
Re: [Help-bash] trap not invoked after resuming read from trap |
Date: |
Tue, 6 Nov 2018 20:55:06 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
On 11/6/18 8:09 PM, Owen Stephens wrote:
> On Tue, Nov 6, 2018 at 9:19 PM Chet Ramey <address@hidden> wrote:
>>
>> Here's what happens. The shell receives SIGINT and sets a flag noting it.
>> The SIGINT interrupts read(2), and the shell notices the -1/EINTR and runs
>> the SIGINT trap. That's not strictly the way things should happen, since
>> traps are run at command boundaries and the read builtin doesn't complete,
>> but it is what people expect.
>
> When you say "That's not strictly the way things should happen" are you
> referring to the manual:
> https://www.gnu.org/software/bash/manual/bash.html#Signals
> specifically, "If Bash is waiting for a command to complete and receives a
> signal for which a trap has been set, the trap will not be executed until the
> command completes"? It would indeed be strange if SIGINT didn't interrupt a
> pending read.
Maybe. People expect the read to be restarted if the signal is trapped and
the trap handler doesn't exit the shell, but they expect the trap handler
to be executed. This is analogous to signal handlers.
> I note that the manual 6.11 Bash POSIX Mode section says "The read builtin may
> be interrupted by a signal for which a trap has been set. If Bash receives a
> trapped signal while executing read, the trap handler executes and read
> returns
> an exit status greater than 128." and indeed, using --posix, my script
> performs
> as I originally expected, namely exiting with 130 after a single Ctrl-C. What
> is the reason for behaving differently without --posix in this regard?
Posix mode never restarts a read on SIGINT, trap or no trap. That's rarely
what people want.
>> There are a couple of things to do, all involving checking for terminating
>> signals before resuming the read. I'll do one of them.
>
> Will this mean that my example _will_ exit after a single Ctrl-c? What are the
> couple of things to do, and what behaviour will they change?
Yes, checking for terminating signals before resuming the read means that
it will note the receipt of a terminating signal and exit before the read
resumes.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU address@hidden http://tiswww.cwru.edu/~chet/