Re: [Help-bash] Signal delivery and select/read

[Chet Ramey]

On 4/20/19 3:58 AM, Andreas Kusalananda Kähäri wrote:
> Hi,
> 
> I really just want to get some clarification and rationale behind how
> "select" works vs. how "read" works when a signal is caught by a trap.
> 
> The observed behaviour (in a script, running under bash 5.0.3 on OpenBSD
> 6.4) is that if a trap is installed for e.g. SIGINT, then that signal
> will be handled by the trap when the body of the "select" loop is about
> to be executed, not while the "select" is waiting for user input.

Yes. Even though the select command uses the read builtin behind the
scenes, it allows the read builtin to complete (or be interrupted)
before running the trap.


> However, "select" is a reserved word, not a command (the "select" loop
> is a compound command though), and for something like "read", the trap
> is executed immediately (and control is then handed back to the "read"
> built-in).

The behvior of `read' is backwards compatible with historical bash behavior
and conforms with user expectations. The idea is that a trapped signal
doesn't cause the read builtin to be interrupted unless the trap handler
does it (using something like `exit'). A user expects a script to exit if
he hits ^C when SIGINT is not trapped, and likewise expects a script to
exit when he hits ^C if a trap handler contains `exit', rather than having
to type something to force the read builtin to complete, so the code runs
traps if read(2) returns -1/EINTR and restarts the read if the trap handler
returns.

Posix mode doesn't restart the read(2) if it returns -1/EINTR.

I can see arguments for the current select behavior and the behavior where
it more closely mimics the `read' builtin. Which do you think works better?

-- 
``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/