I wonder how the following script is supposed to behave.
The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says:
"[...] a signal specified using a symbolic name, without the SIG prefix,
as listed in the tables of signal names in the <signal.h> header defined
in XBD Headers"; there, SIGCHLD is listed as "Child process terminated,
stopped, [XSI] or continued". From this spec, I would assume that the
trap would be executed for any child process that terminates, stops, or
continues. But this is not what I observe.
Only bash, ksh93 and zsh document what happens concerning SIGCHLD traps.
Note: For practical reasons, I assume a sleep implementation with
a floating-point number; this is the case with /bin/sleep under
Debian (coreutils). It could be any external command with a similar
behavior.
------------------------------------------------------------------------
#!/bin/sh
n=${1:-30}
n=$((n+0))
c=0
trap 'c=$((c+1))' CHLD
for i in `seq $n`; do /bin/sleep 0.1 & done
while true
do
echo $c
/bin/sleep 0.1
done
------------------------------------------------------------------------
I call this script with:
<shell> <script_name>
Under Debian unstable:
* With ash, dash, mksh and yash, I get:
1
2
3
4
5
6
[...]
and each time, $c is increased by 1.
The +1 comes from the "/bin/sleep 0.1" of the "while" loop ("true"
and "echo" being built-ins). If I replace them by external commands
(/bin/true and /bin/echo), I get +3 each time.
So, I get +1 only for commands that are not executed in background
(asynchronously).
* With bash and posh, I get:
0
0
0
0
0
0
[...]
i.e. no trap executions at all.
If I add "set -m", then bash behaves like ash, etc., except that it
no longer reacts to Ctrl-C (the Ctrl-C only interrupts the sleep).
Anyway, "set -m" is not supposed to be used in shell scripts (see
rationale for the "set" built-in).
* With ksh93 and zsh, I get:
0
30
30
30
30
30
[...]
(or with a 29 just after the 0 -- this is just a timing reason),
i.e. a trap execution only for asynchronous lists.
This corresponds to the behavior of ksh88 as mentioned in the
rationale for the "set" built-in. Is this the original intent?
In any case, I think that this is the most useful behavior.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
