bash-5.0.3, - is it what is marked [Bash-5.0 patch 3: improve...] in bash.git?
Just built and tested it. The systems are x86-64.
+ Debian GNU/Linux buster/sid (pre-10): works (both exit traps are invoked)
(runs in virtual machine)
kernel-4.18.0-3-amd64, glibc-2.28-6
- CentOS Linux 7.2.1511: NOT work (subshell exit trap is NOT invoked)
(runs on real hardware)
kernel-3.10.0-327.36.3.el7.x86_64, glibc-2.17
- Oracle Solaris 11.3: NOT work (subshell exit trap is NOT invoked)
(runs on real hardware)
system/kernel/platform 0.5.11-0.175.3.1.0.4.0
system/library 0.5.11-0.175.3.1.0.3.0
What can I do to help you isolate this issue?
Best regards,
Konstantin Andreev
Chet Ramey, 26 Mar 2019 16:57 MSK:
I can't reproduce this using RHEL 7 or Mac OS X using bash-5.0.3.
Konstantin Andreev, 25 Mar 2019 22:48 MSK:
Consider the simple `ssxtrap' script:
| #!/bin/bash
|
| echo ext pid=$BASHPID
| # trap 'echo "ext exit trap in $BASHPID"' EXIT
|
| (echo int pid=$BASHPID
| trap 'echo "int exit trap in $BASHPID"' EXIT
| sleep 99999) &
|
| wait
| echo "subshell done"
[ ... skip ... ]
... but if I uncomment the line that installs exit trap in the main shell, the
output changes to:
Terminal A Terminal B
---------- -----------
| $ ./ssxtrap
| ext pid=10373
| int pid=10374
| $ kill 10374
| ./ssxtrap: line 10: 10374 Terminated ...
| subshell done
| ext exit trap in 10373
i.e. subshell exit trap is not invoked anymore.
Since subshell exit trap shall not depend from main shell exit trap, this
behaviour looks like a bug for me.
