! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
disconnected 'screen' session causes loss of scrollbar
Status:
RESOLVED: FIXED
Product:
Xfce4-terminal
Component:
General

Comments

Description antisol 2015-02-25 14:12:10 CET
After losing a connection to an SSH session with 'screen' running it's not possible to scroll a terminal window

To replicate:
0. Open xfce terminal, type stuff to get a healthy scrollbar in your terminal window (ls -l will do). You should be able to scroll back and see history.
1. SSH to a machine where screen is installed (xubuntu: apt-get install screen)
2. Unplug your network cable
3. type / wait until ssh connection dies.
4. Note the scrollbar - there's no way to scroll up.

This can be worked-around by re-connecting to a screen session and detaching or exiting, either remotely or locally e.g:
1. On local machine, type 'screen'
2. get a bash prompt inside screen
3. type 'exit' until screen exits normally. Note that the scrollbar comes back and you can scroll up again. But you'll lose all history between the first session dropping out and the second session exiting.

I'm not sure whether this is fixable since it's obviously a condition where screen is unable to send the appropriate escape sequence to tell xfce-terminal to reinstate the scrollbar, and I don't know how you'd go about detecting that an ssh session has gone away. Perhaps there's some command I can use to fix this, as opposed to re-running and exiting a new screen session?

Thanks for your time!
Comment 1 Egmont Koblinger 2015-03-01 22:44:43 CET
Terminals have a so-called "alternate screen" which doesn't have scrollback buffer, anything that's scrolled out on the top are lost.  Apps like mc, vim, less, screen, tmux etc. switch to this mode.  Leaving this mode restores the previous "normal screen" includings its contents along with the scrollback buffer.

When your connection breaks, you get stuck on the alternate screen. To get back, do something like
  echo -ne '\e[?47l'

It also works with 1047 and 1049, there's probably some minor difference between them, I'm not sure.  Also note that "l" disables, "h" enables it, as in high/low.

You might want to type "reset" instead, it's definitely easier to remember, but beware: newer vte versions (to which xfce-terminal will hopefully upgrade soon) intentionally wipe out the whole scrollback on reset, so it's not a good long-term solution.

You can also write a one-liner shell script or alias with an easy-to-remember name.

You might even experiment with placing the escape sequence in $PS1, just remember to surround it with \[ \] (as bash requires for unprintable characters) and make it conditional to not being inside screen (which you can probably detect from $TERM).
Comment 2 antisol 2015-03-02 10:02:38 CET
Thanks very much for your help, the echo sequence you provided does the trick and I've set up an alias for it. Also the idea of putting it in PS1 is a good one, I'll do some hacking and see what I can come up with.

Thanks! :)
Comment 3 Egmont Koblinger 2015-03-02 15:40:59 CET
You're welcome :)

To correct myself: even older vte (like the one xfce-terminal uses) wipes out the scrollback on "reset".
Comment 4 antisol 2015-03-03 06:25:49 CET
for the record and to help peeople in the future, using $TERM to detect the terminal and putting this in PS1 as suggested works well. To set this up it edit your ~/.bashrc file and add something like the following:

RESET=""
if [ "$TERM" != "screen" ]; then
    RESET="\[\e[?47l\]"
fi  
PS1="$RESET$PS1"

You'll need to source your bashrc (. ~/.bashrc) in each terminal tab or restart your terminal for it to take effect

Notes:

* it occurs to me that there may be other tests you need to make other than "if $TERM is not 'screen'", particularly if you're using something else like tmux.

* My experiments seem to indicate that in the case of screen the test is not necessary at all - screen seems to re-set the alternate mode by itself, or suppress this string, or something like that - If you take the test out it still seems to work just fine. But I think it's probably best to play it safe and do the test.

Bug #11602

Reported by:
antisol
Reported on: 2015-02-25
Last modified on: 2015-03-03

People

Assignee:
Nick Schermer
CC List:
1 user

Version

Attachments

Additional information