bugGNU Screen - Bugs: bug #63341, Copy mode (Ctrl-A ESC) blocks...

 
 

bug #63341: Copy mode (Ctrl-A ESC) blocks stdout

Submitter:  None
Submitted:  Thu 10 Nov 2022 07:24:54 PM UTC
Votes: 87
 
Category:  Program Logic Severity:  3 - Normal
Priority:  * 5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  None
Fixed Release:  None Planned Release:  None
Work Required:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 01 Feb 2024 05:02:24 PM UTC, comment #5: 

I confirm the belowmentioned behavior. My script execution has been suspended without any notice due to stdout block.

Let me vote for the solution as described:

> The memory requirement is only 2X: when entering copy mode, duplicate the history buffer. Execution proceeds "in the background" using its own buffer.


+1 for that version

Zsombor Kalo <zsombor>
Thu 13 Jul 2023 01:24:55 PM UTC, comment #4: 

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.


Yuting Zhang <ritchiez>
Sat 25 Mar 2023 02:53:12 PM UTC, comment #3: 

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@




Anonymous
Fri 11 Nov 2022 12:40:16 AM UTC, comment #2: 

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.

Paul Marks <pmarks>
Thu 10 Nov 2022 07:41:16 PM UTC, 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.

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.

Stephane Chazelas <stephanechazelas>
Thu 10 Nov 2022 07:24:54 PM UTC, original submission:  

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

Anonymous

 

(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

 

Carbon-Copy List
  • -email is unavailable- added by zsombor (Voted in favor of this item)
  • -email is unavailable- added by zsombor (Posted a comment)
  • -email is unavailable- added by ritchiez (Posted a comment)
  • -email is unavailable- added by pmarks (Posted a comment)
  • -email is unavailable- added by stephanechazelas (Posted a comment)
  •  

    There are 87 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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-02-01 zsombor Carbon-Copy- Added zsombor

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code