Dealing with SIGHUP

[lvirden@yahoo.com]

I recently read a mailing list 'posting' that claimed that if
one typed

(program arguments) </dev/null >> stdout 2>>stderr &

that the resulting program would not die from a SIGHUP when the user
initiating the program logged off.

Is that the general case in some/most/all shells?

I thought that to prevent SIGHUPs from killing your shell, you either
had to invoke the command using nohup, write SIGHUP handling code
yourself (assuming the shell allows it), or add code to the application to do
the SIGHUP handling
--
The Tenth Annual Tcl/Tk Conference <URL: [url]http://www.tcl.tk/community/tcl2003[/url] >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@yahoo.com > <URL: [url]http://www.purl.org/NET/lvirden/[/url] >

[Anthony Mandic]

[email]lvirden@yahoo.com[/email] wrote:

>
> I recently read a mailing list 'posting' that claimed that if
> one typed
>
> (program arguments) </dev/null >> stdout 2>>stderr &
>
> that the resulting program would not die from a SIGHUP when the user
> initiating the program logged off.

The example given looks a little strange. Not sure why they want
to read from /dev/null unless the program expects input - in which
case backgrounding it isn't a very good idea. The output redirection
looks silly too. ">>" means append. Are they appending to existing
files?

> Is that the general case in some/most/all shells?

It depends on the shell.

> I thought that to prevent SIGHUPs from killing your shell,

Do you mean "prevent SIGHUPs from killing your process" here?

> you either had to invoke the command using nohup, write SIGHUP handling code
> yourself (assuming the shell allows it), or add code to the application to do
> the SIGHUP handling

Using nohup is the standard method but its not needed with all
shells/programs. Handling a SIGHUP signal in the program itself
is a good idea but you also really need to be careful about
handling input and output. For some programs that expect no input
and write to a log file or have their output redirected its not
a problem.

-am © 2003

[Richard L. Hamilton]

In article <RzXMa.7$Qd3.92@paloalto-snr1.gtei.net>,
Barry Margolin <barry.margolin@level3.com> writes:

> In article <XHKMa.1894$GF2.1498733@twister.nyc.rr.com>,
> <Cypherpunk@nyc.rr.com> wrote:

>>Anthony Mandic <gf@hotmail.com> wrote:

>>> [email]lvirden@yahoo.com[/email] wrote:
>>> >
>>> > I recently read a mailing list 'posting' that claimed that if
>>> > one typed
>>> >
>>> > (program arguments) </dev/null >> stdout 2>>stderr &
>>> >
>>> > that the resulting program would not die from a SIGHUP when the user
>>> > initiating the program logged off.
>>>
>>> The example given looks a little strange. Not sure why they want
>>> to read from /dev/null...

>>
>>I've experience an 'rsh' sucking so hard on stdin that
>>it advanced the place in the shell script that it was
>>in where further commands were read from. (A number of
>>commands after the 'rsh' in the shell script were skipped.)

>
> That doesn't seem likely. When a shell is running a script, the script is
> not the standard input. The only way I can see that happening is if you
> did:
>
> sh < scriptname
>
> instead of
>
> sh scriptname
>
> or
>
> scriptname
>
> Perhaps what you're thinking of is cases like:
>
> while read line;
> do
> rsh ...
> done < filename
>
> This will only call rsh once, for the first line in filename, because rsh
> will suck the rest of the file in.

The solution to that would seem to be

while read line;
do
echo "$line"|rsh ...
done < filename

although ksh print -r - "$line"
would seem to be better than echo, 'cause it doesn't do escape sequences.

--
mailto:rlhamil@mindwarp.smart.net [url]http://www.smart.net/~rlhamil[/url]

[Barry Margolin]

In article <vg9cijl1vqhm4f@corp.supernews.com>,
Richard L. Hamilton <Richard.L.Hamilton@mindwarp.smart.net> wrote:

>In article <RzXMa.7$Qd3.92@paloalto-snr1.gtei.net>,
> Barry Margolin <barry.margolin@level3.com> writes:

>> Perhaps what you're thinking of is cases like:
>>
>> while read line;
>> do
>> rsh ...
>> done < filename
>>
>> This will only call rsh once, for the first line in filename, because rsh
>> will suck the rest of the file in.

>
>
>The solution to that would seem to be
>
>while read line;
>do
> echo "$line"|rsh ...
>done < filename
>
>although ksh print -r - "$line"
>would seem to be better than echo, 'cause it doesn't do escape sequences.

The usual solution is:

while read line;
do
rsh -n ...
done < filename

or

while read line;
do
rsh ... </dev/null
done < filename

Your version will work, but a reader of the code might assume that the
command being rsh'ed actually uses the string that you're echoing to it, so
it's a confusing way to write it.

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.