This is the mail archive of the
mailing list for the Cygwin project.
Re: bash and '&'
- To: Earnie Boyd <earnie_boyd at hotmail dot com>
- Subject: Re: bash and '&'
- From: Fergus Henderson <fjh at cs dot mu dot OZ dot AU>
- Date: Wed, 8 Apr 1998 03:52:29 +1000
- Cc: gnu-win32 at cygnus dot com, wku1 at utk dot edu
- References: <firstname.lastname@example.org>
> "Wei Ku" <email@example.com> 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 <firstname.lastname@example.org> 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
> ---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@example.com> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger firstname.lastname@example.org | -- the last words of T. S. Garp.
For help on using this list (especially unsubscribing), send a message to
"email@example.com" with one line of text: "help".