15

I use GNU Screen's scrollback/copy mode. So I hit Control-A [ to enter copy mode, scroll up to the section I care about... and then I forget.

However, it seems like leaving GNU screen in scrollback/copy mode blocks execution of (whatever app was up at the time). For example, if I fire up a local webserver if I'm in scrollback/copy mode, then requests made to that web server will time out: the process doesn't respond until I exit copy/scrollback mode.

I've seen this both in Ruby On Rails script/server and with the Python tool Paste.

I've considered turning on logging mode for my windows, then just tailing/grepping through those logfiles as an alternative, but if this can be controlled by another means (setting, activating copy mode a different way) I'm very interested.

My screen -version says:

Screen version 4.00.03 (FAU) 23-Oct-06

(I asked this on quora.com, but maybe this is a better place)

Improve this question

2 Answers 2

Reset to default
9

The reason that your processes are blocking is because screen will block the output pipe of the process while you are in copy paste mode. I don't see it as really being a bug, since realistically you are asking screen to store a potentially unlimited amount of information in its buffer while you are copy/pasting. If you want to have output of a program pass by, but also be able to pause it once in a while, try this.

program > logfile 2>&1 & 
less logfile

The 2>&1 will combine stderr and stdout from your program. The & sends the program into the background. Use fg to bring it to the foreground if you need. Now press F to follow the end of the logfile as it grows with less. Press ctrl+c if you need to stop and examine something, then F to follow again. You can also press & to limit the visible lines in less to a regular expression. Very handy when going through log files.

Improve this answer
3
  • 1
    "screen will block the output pipe of the process while you are in copy paste mode" - this might be true once a certain amount of output has been generated, but it doesn't seem to be true in this case: while ((1)) ; do echo $i; i=$((i+1)); sleep 0.1; done - try invoking Copy mode and wait a bit. When you exit copy mode, the value of i will have jumped, showing that execution continued in the background. Yet I have seen screen block output for some processes, so I'm curious as to what exactly determines whether screen blocks or not.
    – davidA
    Commented Feb 2, 2018 at 1:28
  • "what exactly determines whether screen blocks or not" - the size of scrollback buffer determines it. You can increase it to be unlimited, but this will take memory. But will not block.
    – san
    Commented Mar 31, 2018 at 9:10
  • The problem is that you can by accident close a shell with screen in copy mode and it will essentially block all the execution of the program which you find out about many hours later. That's probably because the program waits until there is some free space in pipe again.
    – clime
    Commented Jan 31, 2022 at 9:46
1

I suspect there is no solution without modifying screen, but I made this scroll.py script to at least demonstrate the problem:

#!/usr/bin/env python3
import time
with open("/tmp/scroll", mode="w") as f:
    t1 = time.time()
    while True:
        t2 = time.time()
        tdiff = t2 - t1
        t1 = t2
        text = f"tdiff={tdiff} {'!!!!!!!!' if tdiff > 0.5 else ''}"
        print(text, flush=True)
        print(text, flush=True, file=f)
        time.sleep(0.01)

Run ./scroll.py in a screen session, and tail -f /tmp/scroll in another terminal. Press Ctrl-A ESC to enter copy mode. After a few seconds, the tail output freezes, and exiting copy mode generates this output:

tdiff=0.010303020477294922 
tdiff=5.808627605438232 !!!!!!!!
tdiff=0.010957002639770508

Bug report: https://savannah.gnu.org/bugs/index.php?63341

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .