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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
