Hacker News Reader

Comment by outworlder | Hacker News Reader

> Take away the ownership from the shell using disown

Interesting. So far, my only ever use of disown was to decouple GUI apps that I launched from the terminal. I do that automatically now, as it's annoying when you forget, close the terminal, and a bunch of apps go away.

View on HN

Just for curiosity: what was the purpose of "disown"? If I recall correctly, it was used so the shell you used to launch the process didn't kill it using a "hang" signal or something like that. But I made a quick test and my shell doesn't seem to kill the background process launched from it, at least when I quit using ctrl + d.

Behaviour depends on your shell. With Bash, for instance:

> The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. [...] To prevent the shell from sending the SIGHUP signal to a particular job, it should be removed from the jobs table with the disown builtin (see Job Control Builtins) or marked to not receive SIGHUP using disown -h.

> If the huponexit shell option has been set with shopt (see The Shopt Builtin), Bash sends a SIGHUP to all jobs when an interactive login shell exits.

https://www.gnu.org/software/bash/manual/html_node/Signals.h...

Thanks! I've been doing some tests with the huponexit option but it seems the tricky part was this: when an interactive login shell exits

I think I remember in Linux many years ago (more than 15, maybe) the behavior was present in shells spawned from your DE, but I may be wrong.

Use a terminal like kitty that does not close as long as some launched program is still connected to it. https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.close_on_chi...

How does this compare to using

    nohup <gui-app> &

?

Reply on news.ycombinator.com