How do I implement/enable blanket nohup in the shell?
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
Something like a shell option or "mode" that protects all GUI processes run within that session from being killed when I kill the shell. It would be the equivalent of using nohup for each of the processes.
bash nohup
asked Feb 7 at 19:18
argle
331115
add a comment |Â
up vote
0
down vote
favorite
Something like a shell option or "mode" that protects all GUI processes run within that session from being killed when I kill the shell. It would be the equivalent of using nohup for each of the processes.
bash nohup
asked Feb 7 at 19:18
argle
331115
To make this extra clear. I want to be able to kill the shell (including its virtual terminal, or tmux, or screen) without this killing its processes. So no, by shell I did not just mean virtual terminal.
– argle
Feb 7 at 21:51
Shell has no way of knowing whether or not if process is GUI program or not, so I doubt there's a way to "automate" that. Personally, if I know it's a GUI app, I run it withnohup gui_app > /dev/null 2>&1 &right away.
– Sergiy Kolodyazhnyy
Feb 7 at 22:54
Yes, but the shell has no way of knowing whether the process is GUI or not either.
– argle
Feb 7 at 23:03
And your point is ?
– Sergiy Kolodyazhnyy
Feb 7 at 23:28
My nohup mode doesn't care if things break with some applications. It was an argument against "shifting the... question".
– argle
Feb 8 at 8:37
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Something like a shell option or "mode" that protects all GUI processes run within that session from being killed when I kill the shell. It would be the equivalent of using nohup for each of the processes.
bash nohup
asked Feb 7 at 19:18
argle
331115
Something like a shell option or "mode" that protects all GUI processes run within that session from being killed when I kill the shell. It would be the equivalent of using nohup for each of the processes.
bash nohup
asked Feb 7 at 19:18
argle
331115
asked Feb 7 at 19:18
argle
331115
asked Feb 7 at 19:18
argle
331115
asked Feb 7 at 19:18
argle
331115
331115
To make this extra clear. I want to be able to kill the shell (including its virtual terminal, or tmux, or screen) without this killing its processes. So no, by shell I did not just mean virtual terminal.
– argle
Feb 7 at 21:51
Shell has no way of knowing whether or not if process is GUI program or not, so I doubt there's a way to "automate" that. Personally, if I know it's a GUI app, I run it withnohup gui_app > /dev/null 2>&1 &right away.
– Sergiy Kolodyazhnyy
Feb 7 at 22:54
Yes, but the shell has no way of knowing whether the process is GUI or not either.
– argle
Feb 7 at 23:03
And your point is ?
– Sergiy Kolodyazhnyy
Feb 7 at 23:28
My nohup mode doesn't care if things break with some applications. It was an argument against "shifting the... question".
– argle
Feb 8 at 8:37
add a comment |Â
To make this extra clear. I want to be able to kill the shell (including its virtual terminal, or tmux, or screen) without this killing its processes. So no, by shell I did not just mean virtual terminal.
– argle
Feb 7 at 21:51
Shell has no way of knowing whether or not if process is GUI program or not, so I doubt there's a way to "automate" that. Personally, if I know it's a GUI app, I run it withnohup gui_app > /dev/null 2>&1 &right away.
– Sergiy Kolodyazhnyy
Feb 7 at 22:54
Yes, but the shell has no way of knowing whether the process is GUI or not either.
– argle
Feb 7 at 23:03
And your point is ?
– Sergiy Kolodyazhnyy
Feb 7 at 23:28
My nohup mode doesn't care if things break with some applications. It was an argument against "shifting the... question".
– argle
Feb 8 at 8:37
To make this extra clear. I want to be able to kill the shell (including its virtual terminal, or tmux, or screen) without this killing its processes. So no, by shell I did not just mean virtual terminal.
– argle
Feb 7 at 21:51
To make this extra clear. I want to be able to kill the shell (including its virtual terminal, or tmux, or screen) without this killing its processes. So no, by shell I did not just mean virtual terminal.
– argle
Feb 7 at 21:51
Shell has no way of knowing whether or not if process is GUI program or not, so I doubt there's a way to "automate" that. Personally, if I know it's a GUI app, I run it with
nohup gui_app > /dev/null 2>&1 & right away.– Sergiy Kolodyazhnyy
Feb 7 at 22:54
Shell has no way of knowing whether or not if process is GUI program or not, so I doubt there's a way to "automate" that. Personally, if I know it's a GUI app, I run it with
nohup gui_app > /dev/null 2>&1 & right away.– Sergiy Kolodyazhnyy
Feb 7 at 22:54
Yes, but the shell has no way of knowing whether the process is GUI or not either.
– argle
Feb 7 at 23:03
Yes, but the shell has no way of knowing whether the process is GUI or not either.
– argle
Feb 7 at 23:03
And your point is ?
– Sergiy Kolodyazhnyy
Feb 7 at 23:28
And your point is ?
– Sergiy Kolodyazhnyy
Feb 7 at 23:28
My nohup mode doesn't care if things break with some applications. It was an argument against "shifting the... question".
– argle
Feb 8 at 8:37
My nohup mode doesn't care if things break with some applications. It was an argument against "shifting the... question".
– argle
Feb 8 at 8:37
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
-1
down vote
One solution is to run all commands inside of a terminal multiplexer like tmux or GNU screen. Then if you detach from the tumx or screen session or are disconnected from an ssh session, the commands you are running will continue and not get a SIGHUP. You can reattach and essentially pick up where you left off.
This method is a great way to do any remote administration where you do not want to get disconnected while doing something important or long running.
answered Feb 7 at 19:21
datUser
2,2811032
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
also no protection against lasers either.
– datUser
Feb 7 at 19:25
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
-1
down vote
One solution is to run all commands inside of a terminal multiplexer like tmux or GNU screen. Then if you detach from the tumx or screen session or are disconnected from an ssh session, the commands you are running will continue and not get a SIGHUP. You can reattach and essentially pick up where you left off.
This method is a great way to do any remote administration where you do not want to get disconnected while doing something important or long running.
answered Feb 7 at 19:21
datUser
2,2811032
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
also no protection against lasers either.
– datUser
Feb 7 at 19:25
add a comment |Â
up vote
-1
down vote
One solution is to run all commands inside of a terminal multiplexer like tmux or GNU screen. Then if you detach from the tumx or screen session or are disconnected from an ssh session, the commands you are running will continue and not get a SIGHUP. You can reattach and essentially pick up where you left off.
This method is a great way to do any remote administration where you do not want to get disconnected while doing something important or long running.
answered Feb 7 at 19:21
datUser
2,2811032
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
also no protection against lasers either.
– datUser
Feb 7 at 19:25
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
One solution is to run all commands inside of a terminal multiplexer like tmux or GNU screen. Then if you detach from the tumx or screen session or are disconnected from an ssh session, the commands you are running will continue and not get a SIGHUP. You can reattach and essentially pick up where you left off.
This method is a great way to do any remote administration where you do not want to get disconnected while doing something important or long running.
answered Feb 7 at 19:21
datUser
2,2811032
One solution is to run all commands inside of a terminal multiplexer like tmux or GNU screen. Then if you detach from the tumx or screen session or are disconnected from an ssh session, the commands you are running will continue and not get a SIGHUP. You can reattach and essentially pick up where you left off.
This method is a great way to do any remote administration where you do not want to get disconnected while doing something important or long running.
answered Feb 7 at 19:21
datUser
2,2811032
edited Feb 7 at 19:24
answered Feb 7 at 19:21
datUser
2,2811032
answered Feb 7 at 19:21
datUser
2,2811032
answered Feb 7 at 19:21
datUser
2,2811032
2,2811032
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
also no protection against lasers either.
– datUser
Feb 7 at 19:25
add a comment |Â
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
also no protection against lasers either.
– datUser
Feb 7 at 19:25
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
... unless systemd gets frisky and for some reason nukes some processes
– thrig
Feb 7 at 19:22
also no protection against lasers either.
– datUser
Feb 7 at 19:25
also no protection against lasers either.
– datUser
Feb 7 at 19:25
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f422633%2fhow-do-i-implement-enable-blanket-nohup-in-the-shell%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
To make this extra clear. I want to be able to kill the shell (including its virtual terminal, or tmux, or screen) without this killing its processes. So no, by shell I did not just mean virtual terminal.
– argle
Feb 7 at 21:51
Shell has no way of knowing whether or not if process is GUI program or not, so I doubt there's a way to "automate" that. Personally, if I know it's a GUI app, I run it with
nohup gui_app > /dev/null 2>&1 &right away.– Sergiy Kolodyazhnyy
Feb 7 at 22:54
Yes, but the shell has no way of knowing whether the process is GUI or not either.
– argle
Feb 7 at 23:03
And your point is ?
– Sergiy Kolodyazhnyy
Feb 7 at 23:28
My nohup mode doesn't care if things break with some applications. It was an argument against "shifting the... question".
– argle
Feb 8 at 8:37