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

[Andreas Kusalananda Kähäri]

On Sat, Apr 20, 2019 at 02:16:16PM -0400, Chet Ramey wrote:
> 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.

Ok.

> 
> 
> > 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?

Well, I could say that I think having them behave the same would be
nice, and being able to interrupt the read of "select" in exactly the
same way as with "read" when a trap handler for SIGINT is installed
would be good.  This was however not an attempt to get anything changed,
just me trying to figure out why the two behaviours were different and
whether the behaviours were documented.

Regards,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.