Hi!

I discovered this issue when working on my script. Based on the
manual, I expected that the INT signal would not be propagated to a
subshell created when calling function `f` asynchronously. So it was
very surprising to find that the signal was, in fact, propagated,
including to the foreground children of that subshell. I believe this
is an issue with the manual. I used clanker assistance to write the
below report but I did the testing manually and read the relevant
manual section by myself, so the report is not an AI hallucination.

The Signals section says:"When job control is not in effect,
asynchronous commands ignore SIGINT and SIGQUIT..."

However, the following script behaves differently:

#!/bin/bash
f() {
    sleep 30
}

f &
wait

Running it as bash test.sh and pressing Ctrl-C causes sleep to receive
SIGINT and terminate:

$ sudo strace -p <sleep-pid> -e signal=all
strace: Process <pid> attached
restart_syscall(<... resuming interrupted read ...>) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

This seems inconsistent with the statement above because f & is an
asynchronous command which creates a background subshell yet that
background subshell clearly receives the INT signal and propagates
that signal to its foreground children.

If the intent is to describe only asynchronous non-builtin commands,
would it be possible to make that explicit? It would also be helpful
if the manual explicitly described the corresponding behavior for
asynchronous builtin commands (such as functions or compound
commands), since the current wording leaves that unclear.

Thank you in advance!

Anton

Reply via email to