Move process to other TTY - linux

Is it possible to move a process from one terminal to another in Linux? For example, if I have executed the "top" command via a gnome-terminal window, I want to move the output shown in the gnome-terminal window to a TTY terminal.

It's too late by the time you've already executed it, but if you recognise in advance that you might want to move it, you can use
screen top
to run top, and then detach from the running process with Ctrl-A and D. After that, you can run
screen -r
from any terminal on the same machine to reattach.
It's very powerful, and does a lot more than just that.

Related

Is it possible to programmatically read the `stdout` of another pty / tty without affecting its behavior?

I am attempting to programmatically read the output written by an application running in a specific tmux pane, so that I can determine when to send-keys to it from a controlling process.
In particular, I would like to automatically enter a password, but I do not want to enter it until I am sure the password prompt has appeared.
My current attempt has been to use tty to find the controlling tty, and then pass it to pyserial to try to read, since it appears to be able to read tty's. Note that in the real application, I have other ways of finding out the tty.
Unfortunately, as soon as I run the following code, the target tmux pane immediately closes.
import serial
ser = serial.Serial('/dev/ttys013', timeout=1)
Is it possible to read from a pty this way?
I am running on OSX, but would appreciate a solution that works on both Linux and OSX.
Typically, with python you would use pexpect to start the program and interact with it via a pty, but if you already have a program running in tmux you could simply use tmux's pipe-pane command to save a copy in a file of what is written to the screen. For example, for a pane number 1 you can give the shell command:
tmux pipe-pane -t 1 'cat >/tmp/capture'
and then tail the file /tmp/capture. (Use tmux pipe-pane -t 1 to stop).
To avoid polling, you can use a fifo instead.

How to Stop & Start Screen Jobs Using Scripts in Linux

I want to use some scripts to stop and start a bunch of programs, each running in a separate linux screen. These programs run continuously and need to be stopped using Ctrl-C.
So I can write some code to stop a screen:
screen -S "mysessionname" -X quit
but do I need to send a Ctrl-C somehow first of all and if so then how?
Also, I can start a new detached screen thus from within a script:
screen -mdS "mysesssionname"
but how can I then kick of the job from within this screen using a script? I've tried attaching to the session and then starting the job all from within a script but it doesn't seem to work
Well let's hope that this can help you but to simulate the Ctrl-C in a script as far as i know you can use something like kill -3 and the pid of the process. See in manual of signals: "man 7 signal"

The GNU screen is unresponsive, seems blocked

GNU Screen seems to freeze. Unable to enter user input.
I was using GNU screen and when I pressed the screen it became unresponsive. I can execute all the GNU screen commands, but can't enter user input. I don't want to kill this screen as I have important work and I don't want to lose it.
In the commands below, replace Ctrl with whatever your escape key is for screen commands.
Try Ctrl+a q, which is the sequence to unblock scrolling.
Ctrl+a s is the sequence that blocks scrolling, which makes screen seem like it freezes.
When using PuTTY, you can get an apparently freezed screen if you press Ctrl+s.
This sends an Xoff signal blocking the terminal's output.
The solution is to press Ctrl+q to send the Xon signal.
The above works great if that is your issue.
This could also happen if you're ssh'd into another machine and haven't been to the window in awhile, then when you go back it's frozen. To fix this, you can try the following:
1) Create a new window
Ctrl-a c
2) ssh into the box where you ssh'd into the box in the window that's frozen.
3) Find the process the ssh is running under:
ps aux | grep <remote_box_on_frozen_screen>
or
ps aux | grep <your_user_id>
4) Kill the process
kill <process_id>
When you do screen -ls the first number of the screen name is the process id. So if the output is
There is a screen on:
21605.pts-0.Random-server (11/12/2017 11:44:15 PM) (Detached)
1 Socket in /var/run/screen/S-kg.
Then this will kill it:
kill 21605
Notice the number for the kill command is the same as in the screen -ls output.
If you are using backtick commands in status line - that is, if your .screenrc has something like this:
backtick 1 0 60 /some/script.sh
then you want to be sure that the script is fast: apparently backtick execution blocks all IO to screen.
If you make changes to the config, you'll need to restart the screen session (as the config applies only to new sessions).

getting a program to return immediately at the command line so it's not tied to the shell that launched it

Some programs return immediately when launched from the command line, Firefox for example. Most utilities (and all the programs I've written) are tied to the shell that created them. If you control-c the command line, the program's dead.
What do you have to add to a program or a shell script to get the return-immediately behavior? I guess I'm asking two questions there, one for shell scripts and one for general, if they're different. I would be particularly interested to know if there's a way to get an executable jar to do it.
I'm almost embarrassed to ask that one but I can't find the answer myself.
Thanks!
start cmd
on Windows,
cmd &
on *nux
Here substitute
cmd = java -jar JarFile.jar
On *nux the fg and bg commands are your friends as well ...
You need to basically need to fork a process or create a new thread (or pretend to)
in *nux you can do this with an & after the command like this /long/script & or in windows you can create a BATCH file that executes your processes then exits (it does this naturally).
NOTE: there's no particularly good way to reference this process after you're forked it, basically only ps for the process list. if you want to be able to see what the process is doing, check out using screen (another linux command) that will start a session for you and let you "re-attach" to the screen.
to do this, install screen (sudo apt-get install screen or yum install screen). then type screen to create a new session (note, it will look like you didn't do anything). then, run your /long/command (without the &), then press CTRL + A + D (at the same time) to detach from it (it's still running!). then, when you want to re-attach, type screen -r.
Additionally, look for flags in any help message that allow you do this without using the above options (for instance in synergy you can say synergy --background)
A wrapper script consisting of nothing but:
your_prog_or_script &
Will launch the target and exit immediately. You can add nohup to the beginning of that line so it will continue running if the shell is exited.
For an executable program (as opposed to a shell script), on Linux/Unix use fork() and exec() and then exit the parent process, which will return to the shell. For details see the man pages, or some page like http://www.yolinux.com/TUTORIALS/ForkExecProcesses.html.

Run a command in a shell and keep running the command when you close the session

I am using Putty to connect to a remote server. What I want to know is if there is any way to write my commands and allow them to keep running after I close the session with Putty. The reason for this is that I do not want to keep the computer ON all the time. Is there any way to do this?.
Update with the solution
For my question as it is presented the best solution is use one of the commands provided such as nohup, because you do not have to install any additional software. But if you are in the same problem use screen, install it and use it. It is amazing.
I have selected the answer of Norman Ramsey as favourite because propose several solutions using commands and screen. But please check the other answers specially the one of PEZ, then you get an insight of what screen is able todo.
screen! It's the best thing since sliced bread. (Yeah, I know others have already suggested it, but it's so good the whole world should join in and suggest it too.)
screen is like, like, ummmm ... like using VNC or the like to connect to a GUI destop, but for command shell windows. You can have several shell "windows" open at once in the same screen session. You can do stuff like:
Start a screens session using "screen -dR" (get used to using -dR)
run some commands in one window
press CTRL-A,C to create a new window open a file there in vim
press CTRL-A,0 to go back to the first window and issue some command on the file you just edited
CTRL-A, 1 to go back to your vim session
CTRL-A, C for yet another window and maybe do "sudo - su" (because you just happen to need a full root shell)
CTRL-A, 0 and start a background process
CTRL-A, C to create yet a new window, "tail -f" the log for that background process
CTRL-A, d to disconnect your screen then CTRL-D to disconnect from the server
Go on vacation for three weeks
Log on to the server again and issue "screen -dR" to connect to your existing screen session
check the log in the the fourth window with CTRL-A, 3 (it's like you've been there watching it all the time)
CTRL-A, 1 to pick up that vim session again
I guess you're starting to get the picture now? =)
It's like magic. I've been using screen for longer than I can remember and I'm still totally amazed with how bloody great it is.
EDIT: Just want to mention there's now also tmux. Very much like screen, but has some unique features, splitting the windows being the most prominent one.
nohup, disown, and screen are all good but screen is the best because unlike the other two, screen allows you to disconnect from the remote server, keep everything running, and then reconnect later to see what is happening. With nohup and disown you can't resume interacting.
Try using GNU Screen. It allows you to have several shells open at once. And you can disconnect from those running shells (i.e. close session with Putty) and they will keep doing their thing.
What you are looking for is nohup.
See the wiki link for how to use it.
screen is the best.
Try:
screen -dmS "MyTail" tail -f /var/log/syslog
This start command in background.
Use screen -r to list, and or screen -r Mytail to enter session.
If more users need access same session, use: screen -rx MyTail, and both or more users share the session.
If you can't use screen (because, for instance, your SSH session is being programmatically driven), you can also use daemonize to run the program as a daemon.
One way that works well for me is at.
at works like cron, but for a one-time job. I used it today to download a large file without having to keep my session alive.
for example:
$ at 23:55
at> wget http://file.to.download.com/bigfile.iso
at> ^D
You pass at a time (in the future) and it gives you a prompt. You enter the commands you want to run at that time and hit ctrl+d. You can exit out of your session and it will run the commands at the specified time.
Wikipedia has more info on at.
./command & disown
ssh localhost && ./command && exit

Resources