Dear Chet, I read your reply in the mailing list archive. Thanks a lot for the explanation, I get much better ideas about what the shell wants to do for me after reading it. Sorry that I have to reply to my own message rather than yours. I'll subscribe to the mailing list to ensure that this is not needed any more.
Reading your response carefully I think you get most of the things you say you didn't get. For others, I want to add one comment: > trap '' USR1 > > grep SigIgn /proc/$BASHPID/status > > Presumably this reflects it; I don't know how to interpret the output. > This is a bitmask containing ignored signals, where signal n is represented by value (1 << (n - 1)). The 200 is signal 10, i.e., USR1. Then I want to explain what I consider a bug: > ( > > echo subshell $BASHPID > > grep SigIgn /proc/$BASHPID/status > > After setting all the caught signals back to SIG_DFL, this shell, call it > pid 811, sets SIGUSR1 to SIG_IGN, since that is the disposition it had when > its parent was started. This happens before pretty much anything else. > ... > Let's say this process has pid 813. In this subshell, there shouldn't be > any ignored signals after the shell initializes (it's interactive), but it > does this lazily. > If it should be set to SIG_DFL once anything about signals have to be done, why it even attempt to reset it to SIG_IGN after the subshell initialize? And, I cannot say that bringing an ignored signal back alive in the name of "exit handling" is a "correct behavior"... > I get exactly the same results in bash-4.4 running on RHEL7. > I'd like to confirm your results: when I run it once again in my Ubuntu 18 with bash 4.4 I see the same results. After reading your messages I can do simpler checks of the behaviour. First, I test 3 different versions of bash by running: - A: Ubuntu 19.04, bash 5.0.3(1)-release - B: Debian 4.9.189-3, bash 4.4.12(1)-release (Same results on 4.4.20 of Ubuntu 18.04.3) - C: CentOS Linux release 7.7.1908, bash 4.2.46(2)-release Here are the tests: $ trap '' USR1 $ (trap true EXIT; grep Ign /proc/$BASHPID/status) I see: A: SigIgn: 0000000000000200 B: SigIgn: 0000000000000200 C: SigIgn: 0000000000000200 So it is not that within subshells of interactive shells, once you trap EXIT you get the signal handler reset. In all the above cases it didn't happen. Then I test it by running: $ trap '' USR1 $ (trap true EXIT; (grep Ign /proc/$BASHPID/status) ) For this, I get: A: SigIgn: 0000000000000200 B: SigIgn: 0000000000000200 C: SigIgn: 0000000000000000 This is the actual reason why I have my complex test case in the previous mail: in my deployment there is an error, and I go back to a convenient machine running like (C) and try to reproduce it. I suddenly end up with something that causes an error. Then here is what is inspired by your reply: $ trap '' USR1 $ bash $ (trap true EXIT; grep Ign /proc/$BASHPID/status) For this: A: SigIgn: 0000000000000000 B: SigIgn: 0000000000000000 C: SigIgn: 0000000000000200 This is the behaviour I was reporting. The thing is, the behaviour is undocumented, and even if you want to document it you don't know how to do so. On Tue, Oct 15, 2019 at 5:22 PM Isaac To <isaac...@gmail.com> wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-LQgi2O/bash-5.0=. -fstack-protector-strong > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security > uname output: Linux superposition 5.0.0-25-generic #26-Ubuntu SMP Thu Aug > 1 12:04:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.0 > Patch Level: 3 > Release Status: release > > Description: > > When trying to write a program and start it in an initrc script, I > observed a strange behavior: if a subshell is started by a subshell of that > script, and the inner subshell runs "trap ... EXIT", it unsets the signal > ignore flag of other signals. I'm not sure whether this should be called a > bug, or whether it is a problem caused by my own configuration. Anyway > here is how I reproduce my problem. > > Repeat-By: > > $ cat t.sh > echo t $BASHPID > trap '' USR1 > grep SigIgn /proc/$BASHPID/status > bash --rcfile t2.sh > $ cat t2.sh > echo t2 $BASHPID > grep SigIgn /proc/$BASHPID/status > ( > echo subshell $BASHPID > grep SigIgn /proc/$BASHPID/status > ( > echo subsubshell $BASHPID > grep SigIgn /proc/$BASHPID/status > echo trap $BASHPID > trap 'echo hello' EXIT > grep SigIgn /proc/$BASHPID/status > ) > ) > $ ./t.sh > t 15141 > SigIgn: 0000000000000204 > t2 15143 > SigIgn: 0000000000380004 > subshell 15145 > SigIgn: 0000000000000200 > subsubshell 15147 > SigIgn: 0000000000000200 > trap 15147 > SigIgn: 0000000000000000 > hello > $ > > Note that the final SigIgn flag is completely reset, which is what I won't > expect. The same problem won't occur if --rcfile is not used in t.sh. And > the problem also didn't show up in bash 4.4. > >
