On 7/7/26 12:50 PM, Anton wrote:
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:
I can't reproduce this on RHEL or macOS. Running this script and sending
it SIGINT with ^C causes the script to exit but leaves `sleep' running.
Running it with strace on RHEL shows that the shell forked to run the
asynchronous command and the process forked to run the sleep both set
the SIGINT disposition to SIG_IGN.
For instance,
$ cat sigint-script
#!/bin/bash
f() {
sleep 30
}
f &
wait
$ tty
/dev/pts/0
$ ps -t pts/0
PID TTY TIME CMD
1298459 pts/0 00:00:00 bash
1921579 pts/0 00:00:00 ps
chet-mail(1)$ ../bash-5.3-patched/bash ./sigint-script
^C
chet-mail(1)$ ps -t pts/0
PID TTY TIME CMD
1298459 pts/0 00:00:00 bash
1921581 pts/0 00:00:00 bash
1921582 pts/0 00:00:00 sleep
1921583 pts/0 00:00:00 ps
Both the subshell and the `sleep' survived the ^C.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
