Date: Mon, 6 Apr 2020 10:10:47 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <3e31254d-cc8b-221c-ddb9-ea1ea9fa7...@case.edu>
| I wonder if we're talking about the same thing.
We weren't, but it makes little difference.
| I'm talking about how the
| standard says wait will return immediately and then execute the trap
| handler. There's no such wording for read,
Not specifically, what it says is ...
When a signal for which a trap has been set is received while
the shell is waiting for the completion of a utility executing
a foreground command, the trap associated with that signal shall
not be executed until after the foreground command has completed.
And then it goes on to the part about wait, which does say that wait
will stop immediately - the difference being, that other utilities can,
if they want, keep running - and the shell needs to wait for them.
Read is such a utility, and it was running in the foreground in all
given examples.
But read is not supposed to keep on running - since its acton on "async
events" (ie: signals) is "default", and since it has no mechanism to trap
signals itself, unless the shell has ignored sigint the read should get the
default action (as does most other utilities, like ls or cat) and
simply exit when the SIGINT is received.
| so there is some freedom in when the trap handler gets executed.
There is, but not while the utility is still running.
But all of this is immaterial really, as we're discussing a non-posix
operation in bash, and if you're ignoring (deliberately deviating from)
posix, then what the standard says is obviously irrelevant.
| The better question, I think, is whether a posix-mode bash should
| (logically) return from the read builtin before running the trap handler,
Yes, certainly, in posix mode. From what little testing I did, that's
what appears to happen (and what that #58 in the lis of posix mode
differences says happens - read exits with 128+signo status).
One other oddity that might be worth documenting, when "read -e" is
interrupted by a trapped SIGINT, it doesn't flush the input buffer.
(Without -e the terminal driver does it before anything ever gets received).
This seems to be the same in both posix mode, and non-posix mode
(of course, something using posix mode shouldn't be doing read -e
really). If the SIGINT isn't trapped, it aborts the read, in both
modes (posix and not) when "read -e" is used. I assume the SIGINT
handler could use readline functions to cause pending input to be flushed,
but that seems like a lot of work to expect trap handler to do, just to
get the normal SIGINT behaviour.
kre
