Re: bash sends SIGHUP to disowned children in non-interactive mode

[Philip]

> 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