Subject: Re: bash and '&'
From: [email-masked] (Fergus Henderson)

10 Apr 1998 16:01:50 -0700
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: Earnie Boyd <[email-masked]>
Cc: [email-masked], [email-masked]

> "Wei Ku" <[email-masked]> writes:
> >
> >You are right about '&' which originally means "background".
> >
> >However, if one runs a job with '&' in bash or use 'ctrl-z' + "bg"
> >combination to send a job to background, the job will survive even one log
> >out of bash with "exit" command. That it, it is still running with PPID = 1.
> >This is "equivalent" to the functionality of "nohup" command. I accidentally
> >found this nice feature on IBM AIX machine. After that, I have not used
> >"nohup" anymore -- too lazy to type ;-)

Yes, the old Bourne shell used to require the use of `nohup'
in this case, but there newer shells, e.g. `bash' and `tcsh', do not.

`nohup' may still be (marginally) useful because

	(1) bash does not suppress HUPs signals

	    If for example your modem drops carrier and
	    the bash process terminates due to a SIGHUP
	    rather than by exiting normally, then the child
	    processes will still get the SIGHUP.

	    Other ways to avoid this are to use bash 2.0's `disown' command,
	    or to spawn the job in a subshell via `(prog &)' rather than
	    plain `prog &'.

	(2) nohup redirects stdout & stderr

	    You can of course do the same trivially in bash.

	    But if you forget to do this, and then log out,
	    the process may get an error if it tries to write to
	    stdout or stderr, since the output will go to your tty,
	    which may no longer exist, or which may be owned by
	    root or some other user.

On 31-Mar-1998, Earnie Boyd <[email-masked]> wrote:
> ---from bash.info---
> The shell exits by default upon receipt of a `SIGHUP'.  Before exiting, 
> it resends the `SIGHUP' to all jobs, running or stopped.  To
> prevent the shell from sending the `SIGHUP' signal to a particular job, 
> remove it from the jobs table with the `disown' builtin (*note Job 
> Control Builtins::.) or use `disown -h' to mark it to not receive
> `SIGHUP'.
> ---end bash.info---
> 
> I could find no switches to force this to happen automatically.  Perhaps 
> the AIX bash you used was modified to allow this to happen.

You misunderstood.  If bash exits normally, before getting any SIGHUP,
then it won't be around to forward SIGHUPs to the child processes.

With the Bourne shell, background processes are run in the same
process group as the parent shell, so they get SIGHUPs directly
from the OS, without the shell needing to manually forward them.
With bash, background processes are run in their own process group,
so they get SIGHUPs only if the parent shell forwards them; this
means that if the parent shell has exited, then the background
processes do not get SIGHUPs.

However, all of the above discussion is about how things work on Unix.
I don't know what happens under Windows.  I expect that bash behaves
in much the same way, but probably the OS doesn't, so the results may
not be the same.

--
Fergus Henderson <[email-masked]>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger [email-masked]        |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".