URL:
<https://savannah.gnu.org/bugs/?63341>
Summary: Copy mode (Ctrl-A ESC) blocks stdout
Project: GNU Screen
Submitter: None
Submitted: Thu 10 Nov 2022 07:24:54 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Release: None
Discussion Lock: Any
Fixed Release: None
Planned Release: None
Work Required: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Thu 10 Nov 2022 07:24:54 PM UTC By: Anonymous
scroll.py:
#!/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)
Steps to reproduce:
- Run './scroll.py' in a screen session
- Run 'tail -f /tmp/scroll' in another terminal
- Press 'Ctrl-A ESC' to enter copy mode
After a few seconds, the 'tail' output freezes. Exiting copy mode generates
this output:
tdiff=0.010303020477294922
tdiff=5.808627605438232 !!!!!!!!
tdiff=0.010957002639770508
I think this behavior is a bug, because it violates the principle of least
surprise. Scrolling up or selecting text in a terminal should never block
program execution. Screen could be a nice tool for running simple daemons,
except that copy mode is basically an outage generator.
What could screen do when the scrollback buffer is full?
1. Kick the user out of copy mode
2. Make a copy of the currently-visible buffer region
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?63341>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
