In <[EMAIL PROTECTED]>, Ariel Biener
<[EMAIL PROTECTED]> writes:
> Most things you run in the backround (like ftp, irc, and such) install
> their own handlers.
``Oh, really?''
% find /usr/src/usr.bin/ftp/ | xargs grep SIGHUP
%
And as for IRC, it EXITS on a SIGHUP.
% find ircii-2.8.2 | xargs grep SIGHUP
ircii-2.8.2/source/irc.c: (void) MY_SIGNAL(SIGHUP, irc_exit, 0);
ircii-2.8.2/ChangeLog: handlers for SIGHUP/SIGTERM that call
irc_exit().
> In fact, you have to know for sure that the job you run has not installed
> a signal handler.
What are you talking about? In my previous message, I explained why
any program that deals with SIGHUP won't exit when executed from a
shell without job control. If it was run with nohup(1), it will
ignore the SIGHUP sent by the kernel and continue running. If it
installs its own signal handler, that handler will be run; the program
will exit only if its handler causes it to exit, e.g. IRC.
With jobs run from shells with job control, the SIGHUP isn't sent in
the first place. That's the correct way to do things, btw; why kludge
around and disable a signal (nohup) when the kernel offers job control
primitives to do what you want? Fortunately, modern shells have job
control.
> So, practically, the job must:
>
> 1). not be interactive.
Depends. If you expect to run something in the background and still
be able to type input into it, that (of course) won't work. But
expecting that is as reasonable as expecting a ^C you type to the
shell to interrupt background jobs as well. As for output, as long as
the terminal is there you'll see the output (unless the program
notices its in the background and stops producing output). When the
terminal goes away, the program will start getting errors on write()s
to the terminal. Whether it exits or not at that point depends on how
well it is written.
> 2). not install it's own handler.
That has nothing to do with anything, unless the handler causes the
program to exit. Which is why nohup is evil, imho. USE A SHELL WITH
JOB CONTROL.
> If you can make sure that it answers these criteria, then it will work.
> (like backgrounding a matlab job).
>
> If you can't, then you'd better use nohup or screen.
You said jobs run with nohup will ``terminate as soon as they are
detached from the controlling terminal''.
>
> --Ariel
>
>
> P.S. Notice that I am more concerned in giving practical answers, than
> theoretical ones.
Notice that I am more concerned with giving answers that are based on
reality than incorrect ones.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
