On 19/02/2020 20:30, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is delivered before "wait",
then TERM trap will kill the child, and exit.
This strikes me as a shaky assumption, dependent on when the shell receives
the SIGTERM and when it runs traps. (There's nothing in POSIX that says
when pending traps are processed. Bash runs them after commands.)
The bash documentation says traps will not be executed until the command
completes if it receives a signal while waiting for the command to
complete, but it does not say the same for when it receives a signal
before waiting for a command to complete. This may be an oversight in
the documentation.
POSIX says in the description of the trap command "Otherwise, the
argument action shall be read and executed by the shell when one of the
corresponding conditions arises." Because it says "when", not "after",
if interpreted literally, it does not even allow waiting until the
current command finishes executing. I realise that that is definitely
not the way it is meant to be interpreted, but I am not sure what is. I
consider the assumption that the test script is supposed to work a
reasonable one, but it is possible that this is considered strictly a
QoI issue.
But to be clear, regardless of what POSIX requires, I was less concerned
with prodding other shell authors into changing their shells and more
with seeing what I can do in my shell. I want to have a shell that is
capable of handling scripts like this, but it is fine with me if other
shells do not share that as a goal.
Thanks for looking into this despite your scepticism on the validity of
the test. Your description of what happens in bash when this ends up
sleeping probably applies to all shells that behave the same way.
Cheers,
Harald van Dijk