Re: EOF disowns background jobs?

[Chet Ramey]

Matthew Woehlke wrote:
> Chet Ramey wrote:
>> Matthew Woehlke wrote:
>>> $ some-command &
>>> $ ^D
>>> (bash exits, leaving some-command running)
>>>
>>> Is this what is supposed to happen? Just asking because it made me go
>>> "huh?"; I was expecting some-command to get SIGHUP'd.
>>
>> Yes, that's what's supposed to happen.  How could you run daemons from
>> the command line otherwise?
> 
> "disown"?
> 
> What feels weird to me is that if the shell exits because of SIGHUP,
> that gets passed to children, but EOF doesn't do likewise.

Historically, that's because signals were used to indicate exceptional
conditions, like "my terminal/network connection/controlling terminal
has disappeared unexpectedly", whereas EOF is a normal exit.  These
exceptional conditions should be passed on to all the processes with
that controlling terminal.

This behavior far predates "disown."

> However, come to think of it the EOF behavior probably makes more sense
> for non-interactive shells... which throws the question back to the TE.
> I'm curious if you have an opinion; should a TE send EOF or SIGHUP when
> exiting normally but forcefully (i.e. user clicks the WM 'close window'
> button or uses File->Exit)?

EOF.  It should actually make the controlling terminal disappear in such
a way that subsequent reads return EOF (-1/EIO) for all process in the
same process group as the terminal -- an "orphaned process group".  That's
a lot harder than sending SIGHUP, though.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer

Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/