3

I have, for example, a long running and verbose tar cvf /backup/backup.tar command that outputs a lot of text to the screen*. I don't necessarily want to see all of the output all of the time. I'd like to stop the text output, do other stuff, then come back to it and "resume" to see how far along it is in the backup process. I expected it to behave like

/files/big_file_1
/files/big_file_2
/files/big_file_3
# Ctrl+s
# Do other stuff
# Ctrl+q , notice big jump in progress
/home/user/.bash_history
/home/user/small_file_1
/home/user/small_file_2
/home/user/small_file_3
...

Ctrl+s stops output to the screen (and Ctrl+q resumes output to screen), whereas Ctrl+z suspends the process and I'm back to a PS1 prompt. My question is, does Ctrl+s keep the command running?

During the aforementioned tar command, I would highlight the last file TARred let it sit for a few minutes, Ctrl+q, and the next files appeared to be in the same dir, or at least in a relatively close directory.

*I'm using Putty on Windows, so if the behavior is different between that and a standard terminal on Linux/Unix I apologize.

4

My question is, does Ctrl+s keep the command running?

Yes, up to the point where the system buffers fill, and the process starts blocking to be able to write to the terminal. So, it won't run indefinitely. Plus you won't be able to run anything else in the same terminal since the output is blocked.

To switch away from the program while still keeping it possible to come back, the choices are:

  • Run another terminal on the side (another Putty, another SSH connection)
  • Run screen or tmux to multiplex multiple "windows" inside the same terminal
  • Redirect the output to a file, run the command in the background and then peek at the file when you want to: tar cvf ... > /tmp/tar.out & and tail /tmp/tar.out
  • Thank you. I was hoping for some sort of solution after I already started the command, but yours will come in handy if I know ahead of time that I won't need to see all of the output. tmux will likely be the best option because I can detach from the session. Typically, I tend to operate inside a tmux session anyways in case I happen to get disconnected. – user208145 Mar 29 '18 at 21:49
  • This is related, and may be of help stackoverflow.com/q/1323956/537980 – ctrl-alt-delor Mar 29 '18 at 23:23
  • 1
    @user208145, yeah, after starting the program it's probably easiest to just open another terminal on the side. I've seen a script that uses some dark magic to transfer a program to inside screen even if it was started outside, but it's probably not what you really want to use... I do find it easiest to just run everything under screen in any case. It also has the advantage that a random disconnection doesn't kill the processes. – ilkkachu Mar 30 '18 at 9:47
  • Indeed. I use tmux primarily because my screen-fu is sub par. I do use an "@reboot" cron entry to initialize screen to capture serial output from an old Sun server with no monitor. – user208145 Mar 30 '18 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.