Add a New Comment Rich Markup
Another user that gets frustrated by copy mode's getting the running program stuck from time to time.
> The memory requirement is only 2X: when entering copy mode, duplicate the history buffer. Execution proceeds "in the background" using its own buffer.
+1 with this. It seems to be a very decent solution.
I love screen, but I agree that the original posted described a bug. When I enter copy/scrollback mode, I certainly do not intend to "pause the output". All I am trying to do is to scrollback to read the terminal messages that are inaccessible because screen blocks the usual scrolling mechanism. Incidentally, a Google search suggests that a possible solution is to add a line to the .screenrc file: # Enable scrolling termcapinfo xterm* ti@:te@
comment #1:
> To me, it's not a bug and screen behaves as expected. When you enter copy mode, you "pause" the output. screen stops reading the output of the slave and focuses on you selecting what to copy out of what has been output up to that point.
You are describing what screen currently does, but what do users expect it to do? Say Bob runs a bunch of code within screen. It stays running even if his terminal explodes. Would Bob expect a feature named "copy mode" to permanently interrupt execution, even after detaching? Copy mode at least needs an ### EXECUTION HALTED ### banner to communicate its severity.
> > If it were to still read the slave's output while at the same time letting you inspect and copy the earlier output it would potentially have to be able to store indefinite amount of output.
The memory requirement is only 2X: when entering copy mode, duplicate the history buffer. Execution proceeds "in the background" using its own buffer.
To me, it's not a bug and screen behaves as expected. When you enter copy mode, you "pause" the output. screen stops reading the output of the slave and focuses on you selecting what to copy out of what has been output up to that point. If it were to still read the slave's output while at the same time letting you inspect and copy the earlier output it would potentially have to be able to store indefinite amount of output.
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
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only logged-in users can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.12