Pause a process and bring it back to foreground in a separate screen in Ubuntu [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
This question already has an answer here:
How to attach terminal to detached process?
5 answers
A process put to sleep by issuing ^Z can be brought back to the foreground by listing the running jobs $ jobs and giving the job id to fg %id.
But when I tried to list the jobs in a separate screen of the same terminal there was no results. How to achieve this ?
What I want is to start the same process without killing it in a separate screen of the same terminal.
terminal process gnu-screen
asked Jul 19 at 8:19
Gayan Kavirathne
1012
marked as duplicate by Bananguin, schily, thrig, slm♦ Jul 19 at 14:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
add a comment |Â
up vote
0
down vote
favorite
This question already has an answer here:
How to attach terminal to detached process?
5 answers
A process put to sleep by issuing ^Z can be brought back to the foreground by listing the running jobs $ jobs and giving the job id to fg %id.
But when I tried to list the jobs in a separate screen of the same terminal there was no results. How to achieve this ?
What I want is to start the same process without killing it in a separate screen of the same terminal.
terminal process gnu-screen
asked Jul 19 at 8:19
Gayan Kavirathne
1012
marked as duplicate by Bananguin, schily, thrig, slm♦ Jul 19 at 14:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Look into using the screen utility. This will allow you to share terminal sessions
– Raman Sailopal
Jul 19 at 8:22
Can you elaborate bit more what function in screen to use. ?
– Gayan Kavirathne
Jul 19 at 9:02
What does "separate screen" mean?
– muru
Jul 19 at 10:04
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This question already has an answer here:
How to attach terminal to detached process?
5 answers
A process put to sleep by issuing ^Z can be brought back to the foreground by listing the running jobs $ jobs and giving the job id to fg %id.
But when I tried to list the jobs in a separate screen of the same terminal there was no results. How to achieve this ?
What I want is to start the same process without killing it in a separate screen of the same terminal.
terminal process gnu-screen
asked Jul 19 at 8:19
Gayan Kavirathne
1012
This question already has an answer here:
How to attach terminal to detached process?
5 answers
A process put to sleep by issuing ^Z can be brought back to the foreground by listing the running jobs $ jobs and giving the job id to fg %id.
But when I tried to list the jobs in a separate screen of the same terminal there was no results. How to achieve this ?
What I want is to start the same process without killing it in a separate screen of the same terminal.
This question already has an answer here:
How to attach terminal to detached process?
5 answers
terminal process gnu-screen
asked Jul 19 at 8:19
Gayan Kavirathne
1012
edited Jul 19 at 9:03
asked Jul 19 at 8:19
Gayan Kavirathne
1012
asked Jul 19 at 8:19
Gayan Kavirathne
1012
asked Jul 19 at 8:19
Gayan Kavirathne
1012
1012
marked as duplicate by Bananguin, schily, thrig, slm♦ Jul 19 at 14:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by Bananguin, schily, thrig, slm♦ Jul 19 at 14:30
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
Look into using the screen utility. This will allow you to share terminal sessions
– Raman Sailopal
Jul 19 at 8:22
Can you elaborate bit more what function in screen to use. ?
– Gayan Kavirathne
Jul 19 at 9:02
What does "separate screen" mean?
– muru
Jul 19 at 10:04
add a comment |Â
Look into using the screen utility. This will allow you to share terminal sessions
– Raman Sailopal
Jul 19 at 8:22
Can you elaborate bit more what function in screen to use. ?
– Gayan Kavirathne
Jul 19 at 9:02
What does "separate screen" mean?
– muru
Jul 19 at 10:04
Look into using the screen utility. This will allow you to share terminal sessions
– Raman Sailopal
Jul 19 at 8:22
Look into using the screen utility. This will allow you to share terminal sessions
– Raman Sailopal
Jul 19 at 8:22
Can you elaborate bit more what function in screen to use. ?
– Gayan Kavirathne
Jul 19 at 9:02
Can you elaborate bit more what function in screen to use. ?
– Gayan Kavirathne
Jul 19 at 9:02
What does "separate screen" mean?
– muru
Jul 19 at 10:04
What does "separate screen" mean?
– muru
Jul 19 at 10:04
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
The terminal is a viewer onto a process such as the shell. The terminal itself doesn't run any commands - that's the shell's purpose - but without the terminal you cannot interact with the shell or any program it runs.
Normally, when you close a terminal window it sends a signal to the shell to tell it to close down, which in turn kills any process you may have running there.
You can run a process under screen. What this does is create a "virtual terminal" for a shell to run in. Your "real" terminal window can attach to that screen session and control the virtual terminal that screen has provided. The net effect is that it feels perfectly normal BUT you can also detach from the virtual screen and let the shell continue running.
screen # Create a leader and a virtual terminal/screen running a shell
screen -ls # List sessions (attached/detached)
screen -r # Reattach to the single detached session
screen -r identifier # Reattach to the named detached session
screen -md command... # Make a new detached session running command...
Finally, Ctrl Ad detaches from the current session and Ctrl A? gets you the list of interactive commands.
answered Jul 19 at 9:23
roaima
39.2k544105
add a comment |Â
up vote
1
down vote
You can't. The handling of shell jobs (foreground and background processes) is done by each individual shell instance. You can't migrate a job from one interactive shell to another, not even within something like screen.
The terminal doesn't really have anything to do with this. It just runs the shell.
What you may do is to migrate a whole shell session with a terminal multiplexer, such as tmux or screen. A shell session within one of these may be moved to another terminal through detaching the screen or tmux session in one terminal and reattaching to it in another on the same machine.
With tmux this is done by first starting tmux, then starting your program inside of the tmux session. When the program is running, you may press prefixd (prefix is Ctrl+B by default) to detach the tmux session. In another terminal, you then give the command tmux attach to get the tmux session back. Detaching can also be done through the command tmux detach.
See the manuals for screen and tmux on your system.
answered Jul 19 at 8:25
Kusalananda
101k13199311
1
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
1
@StephenKitt Using magic might always be possible, but would it be a better way than doing it withtmux/screen?
– Kusalananda
Jul 19 at 8:34
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it withtmux/screen?"
– Bananguin
Jul 19 at 9:10
1
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
 |Â
show 3 more comments
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The terminal is a viewer onto a process such as the shell. The terminal itself doesn't run any commands - that's the shell's purpose - but without the terminal you cannot interact with the shell or any program it runs.
Normally, when you close a terminal window it sends a signal to the shell to tell it to close down, which in turn kills any process you may have running there.
You can run a process under screen. What this does is create a "virtual terminal" for a shell to run in. Your "real" terminal window can attach to that screen session and control the virtual terminal that screen has provided. The net effect is that it feels perfectly normal BUT you can also detach from the virtual screen and let the shell continue running.
screen # Create a leader and a virtual terminal/screen running a shell
screen -ls # List sessions (attached/detached)
screen -r # Reattach to the single detached session
screen -r identifier # Reattach to the named detached session
screen -md command... # Make a new detached session running command...
Finally, Ctrl Ad detaches from the current session and Ctrl A? gets you the list of interactive commands.
answered Jul 19 at 9:23
roaima
39.2k544105
add a comment |Â
up vote
1
down vote
The terminal is a viewer onto a process such as the shell. The terminal itself doesn't run any commands - that's the shell's purpose - but without the terminal you cannot interact with the shell or any program it runs.
Normally, when you close a terminal window it sends a signal to the shell to tell it to close down, which in turn kills any process you may have running there.
You can run a process under screen. What this does is create a "virtual terminal" for a shell to run in. Your "real" terminal window can attach to that screen session and control the virtual terminal that screen has provided. The net effect is that it feels perfectly normal BUT you can also detach from the virtual screen and let the shell continue running.
screen # Create a leader and a virtual terminal/screen running a shell
screen -ls # List sessions (attached/detached)
screen -r # Reattach to the single detached session
screen -r identifier # Reattach to the named detached session
screen -md command... # Make a new detached session running command...
Finally, Ctrl Ad detaches from the current session and Ctrl A? gets you the list of interactive commands.
answered Jul 19 at 9:23
roaima
39.2k544105
add a comment |Â
up vote
1
down vote
up vote
1
down vote
The terminal is a viewer onto a process such as the shell. The terminal itself doesn't run any commands - that's the shell's purpose - but without the terminal you cannot interact with the shell or any program it runs.
Normally, when you close a terminal window it sends a signal to the shell to tell it to close down, which in turn kills any process you may have running there.
You can run a process under screen. What this does is create a "virtual terminal" for a shell to run in. Your "real" terminal window can attach to that screen session and control the virtual terminal that screen has provided. The net effect is that it feels perfectly normal BUT you can also detach from the virtual screen and let the shell continue running.
screen # Create a leader and a virtual terminal/screen running a shell
screen -ls # List sessions (attached/detached)
screen -r # Reattach to the single detached session
screen -r identifier # Reattach to the named detached session
screen -md command... # Make a new detached session running command...
Finally, Ctrl Ad detaches from the current session and Ctrl A? gets you the list of interactive commands.
answered Jul 19 at 9:23
roaima
39.2k544105
The terminal is a viewer onto a process such as the shell. The terminal itself doesn't run any commands - that's the shell's purpose - but without the terminal you cannot interact with the shell or any program it runs.
Normally, when you close a terminal window it sends a signal to the shell to tell it to close down, which in turn kills any process you may have running there.
You can run a process under screen. What this does is create a "virtual terminal" for a shell to run in. Your "real" terminal window can attach to that screen session and control the virtual terminal that screen has provided. The net effect is that it feels perfectly normal BUT you can also detach from the virtual screen and let the shell continue running.
screen # Create a leader and a virtual terminal/screen running a shell
screen -ls # List sessions (attached/detached)
screen -r # Reattach to the single detached session
screen -r identifier # Reattach to the named detached session
screen -md command... # Make a new detached session running command...
Finally, Ctrl Ad detaches from the current session and Ctrl A? gets you the list of interactive commands.
answered Jul 19 at 9:23
roaima
39.2k544105
answered Jul 19 at 9:23
roaima
39.2k544105
answered Jul 19 at 9:23
roaima
39.2k544105
answered Jul 19 at 9:23
roaima
39.2k544105
39.2k544105
add a comment |Â
add a comment |Â
up vote
1
down vote
You can't. The handling of shell jobs (foreground and background processes) is done by each individual shell instance. You can't migrate a job from one interactive shell to another, not even within something like screen.
The terminal doesn't really have anything to do with this. It just runs the shell.
What you may do is to migrate a whole shell session with a terminal multiplexer, such as tmux or screen. A shell session within one of these may be moved to another terminal through detaching the screen or tmux session in one terminal and reattaching to it in another on the same machine.
With tmux this is done by first starting tmux, then starting your program inside of the tmux session. When the program is running, you may press prefixd (prefix is Ctrl+B by default) to detach the tmux session. In another terminal, you then give the command tmux attach to get the tmux session back. Detaching can also be done through the command tmux detach.
See the manuals for screen and tmux on your system.
answered Jul 19 at 8:25
Kusalananda
101k13199311
1
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
1
@StephenKitt Using magic might always be possible, but would it be a better way than doing it withtmux/screen?
– Kusalananda
Jul 19 at 8:34
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it withtmux/screen?"
– Bananguin
Jul 19 at 9:10
1
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
 |Â
show 3 more comments
up vote
1
down vote
You can't. The handling of shell jobs (foreground and background processes) is done by each individual shell instance. You can't migrate a job from one interactive shell to another, not even within something like screen.
The terminal doesn't really have anything to do with this. It just runs the shell.
What you may do is to migrate a whole shell session with a terminal multiplexer, such as tmux or screen. A shell session within one of these may be moved to another terminal through detaching the screen or tmux session in one terminal and reattaching to it in another on the same machine.
With tmux this is done by first starting tmux, then starting your program inside of the tmux session. When the program is running, you may press prefixd (prefix is Ctrl+B by default) to detach the tmux session. In another terminal, you then give the command tmux attach to get the tmux session back. Detaching can also be done through the command tmux detach.
See the manuals for screen and tmux on your system.
answered Jul 19 at 8:25
Kusalananda
101k13199311
1
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
1
@StephenKitt Using magic might always be possible, but would it be a better way than doing it withtmux/screen?
– Kusalananda
Jul 19 at 8:34
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it withtmux/screen?"
– Bananguin
Jul 19 at 9:10
1
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
 |Â
show 3 more comments
up vote
1
down vote
up vote
1
down vote
You can't. The handling of shell jobs (foreground and background processes) is done by each individual shell instance. You can't migrate a job from one interactive shell to another, not even within something like screen.
The terminal doesn't really have anything to do with this. It just runs the shell.
What you may do is to migrate a whole shell session with a terminal multiplexer, such as tmux or screen. A shell session within one of these may be moved to another terminal through detaching the screen or tmux session in one terminal and reattaching to it in another on the same machine.
With tmux this is done by first starting tmux, then starting your program inside of the tmux session. When the program is running, you may press prefixd (prefix is Ctrl+B by default) to detach the tmux session. In another terminal, you then give the command tmux attach to get the tmux session back. Detaching can also be done through the command tmux detach.
See the manuals for screen and tmux on your system.
answered Jul 19 at 8:25
Kusalananda
101k13199311
You can't. The handling of shell jobs (foreground and background processes) is done by each individual shell instance. You can't migrate a job from one interactive shell to another, not even within something like screen.
The terminal doesn't really have anything to do with this. It just runs the shell.
What you may do is to migrate a whole shell session with a terminal multiplexer, such as tmux or screen. A shell session within one of these may be moved to another terminal through detaching the screen or tmux session in one terminal and reattaching to it in another on the same machine.
With tmux this is done by first starting tmux, then starting your program inside of the tmux session. When the program is running, you may press prefixd (prefix is Ctrl+B by default) to detach the tmux session. In another terminal, you then give the command tmux attach to get the tmux session back. Detaching can also be done through the command tmux detach.
See the manuals for screen and tmux on your system.
answered Jul 19 at 8:25
Kusalananda
101k13199311
edited Jul 19 at 9:26
answered Jul 19 at 8:25
Kusalananda
101k13199311
answered Jul 19 at 8:25
Kusalananda
101k13199311
answered Jul 19 at 8:25
Kusalananda
101k13199311
101k13199311
1
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
1
@StephenKitt Using magic might always be possible, but would it be a better way than doing it withtmux/screen?
– Kusalananda
Jul 19 at 8:34
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it withtmux/screen?"
– Bananguin
Jul 19 at 9:10
1
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
 |Â
show 3 more comments
1
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
1
@StephenKitt Using magic might always be possible, but would it be a better way than doing it withtmux/screen?
– Kusalananda
Jul 19 at 8:34
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it withtmux/screen?"
– Bananguin
Jul 19 at 9:10
1
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
1
1
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
There is a funky way of recovering a background job in a different session, IIRC, I’ll try to find it...
– Stephen Kitt
Jul 19 at 8:33
1
1
@StephenKitt Using magic might always be possible, but would it be a better way than doing it with
tmux/screen?– Kusalananda
Jul 19 at 8:34
@StephenKitt Using magic might always be possible, but would it be a better way than doing it with
tmux/screen?– Kusalananda
Jul 19 at 8:34
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@Kusalananda indeed it is. But think of a situation where the user accidentally starting a process and discover that he forgot to start it in a screen after a considerable amount of the resource and time is consumed by the process, as in perticularyly in my case.
– Gayan Kavirathne
Jul 19 at 9:06
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it with
tmux/screen?"– Bananguin
Jul 19 at 9:10
@StephenKitt Well, essentially you "just" need to attach stdin,out,err of that process to a new subprocess spawned by your shell. If you have ptys allocated this is fairly simple. If it isn't, IIRC there is some dark ritual you can do with gdb, but I'd like to quote @Kusalananda "would it be a better way than doing it with
tmux/screen?"– Bananguin
Jul 19 at 9:10
1
1
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
And yes, I agree @Kusalananda, it’s better to start off in a terminal multiplexer of some sort.
– Stephen Kitt
Jul 19 at 11:28
 |Â
show 3 more comments
Look into using the screen utility. This will allow you to share terminal sessions
– Raman Sailopal
Jul 19 at 8:22
Can you elaborate bit more what function in screen to use. ?
– Gayan Kavirathne
Jul 19 at 9:02
What does "separate screen" mean?
– muru
Jul 19 at 10:04