> It may receive a SIGHUP, but you haven't demonstrated that it's bash > sending the SIGHUP. Since job control isn't enabled, it's most likely > that the SIGHUP xterm sends to the process group when you hit the close > button gets to xclock because it's in the same process group as bash. > > Bash only sends SIGHUP to running jobs of an interactive login shell when > the `huponexit' option is set. It will resend SIGHUP to running jobs > if they haven't been disowned, but the background-process-inside-a-subshell > business means xclock isn't a child process or job of the shell anyway. Yes that why used that background-process-inside-a-subshell because I thought is was a good way to make sure that it won't be a job of the shell. I didn't get anywhere with the strace yet but figured out (thanks to you and Greg) that I get a different behavior with job control enabled.
So let's take these two scripts, clock1.sh and clock2.sh. I know it sounds boring but please bear with me. ------------- #!/bin/bash set -m xclock & sleep 2 -------------- #!/bin/bash -i xclock & sleep 2 -------------- I run them with: xterm -hold -e './clock1.sh' the -hold keeps the xterm window open after the scripts finish. The first script works fine, xclock stays. I don't even have to disown. The second script, xclock appears and disappears after 2 seconds. Received a SIGHUP when the script ended. The xterm window is still there because of the -hold parameter. I get the exact same behavior if I use "(xclock &)" instead. So without job control bash might (I know, we don't know for sure) send the SIGHUP to all processes started in the shell, whether child by definition or not? Shouldn't the -i flag enable job control by the way? Regards, Philip
