From: fjh AT cs DOT mu DOT OZ DOT AU (Fergus Henderson) Subject: Re: bash and '&' 10 Apr 1998 16:01:50 -0700 Message-ID: <19980408035229.39717.cygnus.gnu-win32@murlibobo.cs.mu.OZ.AU> References: <19980331141913 DOT 15879 DOT qmail AT hotmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Earnie Boyd Cc: gnu-win32 AT cygnus DOT com, wku1 AT utk DOT edu > "Wei Ku" 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 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 | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3 | -- the last words of T. S. Garp. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".