Re: signals ignored in a subshell

[Robert Elz]

    Date:        Sun, 5 Apr 2020 16:21:53 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <45c766ba-4489-bd7b-40c7-32fed37461f9@case.edu>

  | That's not how read is defined to behave. wait has special wording defining
  | what happens when it receives a signal.

No, it doesn't, that's a misreading of the standard.

For both read and wait, POSIX says:

ASYNCHRONOUS EVENTS
            Default.

where "default" is defined in XCU 1.4, and is specified to be the
default value for the signal (which for SIGINT is to cause the
process to terminate) unless the parent caused the signal to be ignored
(a utility - including a built-in utility - cannot inherit a trapped (caught)
signal from its parent).

When a SIGINT is received read should terminate, just as wait does, or
any other utility which does not itself catch SIGINT, does.

The wording you're referring to in the description of the wait
utility refers to its exit status, which is fairly precisely specified
for wait (exactly what the status should be in the various cases)
where read is just 0 if everything worked, >0 other cases.

bash and zsh seem to be the only shells that treat read this way, and
bash doesn't do it in POSIX mode, which means, I believe that you're
aware that you're treating read specially, and that what POSIX says about
it is irrelevant.

I'd make this an option to read, rather that a side effect of posix mode,
if I wanted to make it possible to restart reads, and in any case should
be documented.   Yes, I know this is #58 in
         http://tiswww.case.edu/~chet/bash/POSIX
but unless the man page at least hints that the way read works depends
upon posix mode, how would anyone know to look there?

  | Bash default mode behaves as I
  | described previously -- trapping the signal and returning from the handler
  | results in the read being restarted -- and posix mode will run the trap
  | handler before returning from the `read' builtin.

Even that didn't make it clear to me (#58 referred to above is better worded).

It is also worth pointing out, that only a caught signal works that
way, if SIGINT is in its deffault state, read is interrupted by a SIGINT
(the read doesn't restart).

kre

ps: yash is also broken here, but worse, which can only be the result of
a bug, SIGINT never interrupts read there, a SIGINT received while read
is running is acted upon after read completes - regardless of whether
SIGINT is trapped or not.