3 ms·

> 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 termina

> 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.

aumerle 4y ago
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_child_death https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.close_on_chi...
jagged-chisel 4y ago
How does this compare to using nohup <gui-app> & ?
severino 4y ago
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.
- yrro 4y ago
  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.html https://www.gnu.org/software/bash/manual/html_node/Signals.h...
  - severino 4y ago
    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.

aumerle 4y ago

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_child_death https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.close_on_chi...

jagged-chisel 4y ago

How does this compare to using nohup <gui-app> & ?

severino 4y ago

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.

yrro 4y ago
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.html https://www.gnu.org/software/bash/manual/html_node/Signals.h...
- severino 4y ago
  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.