Re: *cause of* screen writing over restored buffer on detach/exit

----- Original Message -----
| From: "Thomas Wolff" <towo@xxxxxxxx>
| To: "cygwin" <cygwin@xxxxxxxxxx>
| Sent: Wednesday, April 10, 2019 5:51:34 PM
| Subject: Re: *cause of* screen writing over restored buffer on detach/exit
| Hi Thomas,
|
| Thomas Dickey wrote:
|> ----- Original Message -----
|> | From: "Shaddy Baddah" <lithium-cygwin@xxxxxxxxxxxxxxxxx>
|> | To: "cygwin" <cygwin@xxxxxxxxxx>
|> | Sent: Tuesday, April 9, 2019 11:18:19 PM
|> | Subject: Re: *cause of* screen writing over restored buffer on detach/exit
|>
|> | On 9/4/19 4:07 pm, Shaddy Baddah wrote:
|> |>
|> |> This helped with screen when using Putty to a Cygwin ssh session. For
|> |> some reason, it isn't helping for running screen locally in a mintty
|> |> session. And it's not mintty either, because I can ssh to a Debian
|> |> stretch server within mintty and I can use its screen without this
|> |> issue happening. Back to the drawing board for me.
|> |
|> | I understand the cause of the issue now, by capturing and comparing the
|> | escape characters used to control the terminal by screen on Cygwin and
|> | Debian.
|> |
|> | It is not so much the detach/exit is the issue, although the escape
|> | sequence for Cygwin includes a couple of extra xterm OSC Set Text
|> | Parameters -> Change Icon Name and Window Title outputs. I misdiagnosed
|> | this somehow. I can suppress the extra utmp error one of these OSC
|> | outputs, but it didn't/doesn't really make a difference.
|> |
|> | The issue is in the escape sequences sent to the terminal by Cygwin
|> | screen to switch to new windows buffer, as compared to Debian.
|> |
|> | Debian uses xterm sequence DECSET / ESC[?1049h in the switch to the new
|> | window. Cygwin uses the two sequences ESC7 / Save Cursor (DECSC) and
|> | ESC[?47l / DEC Private Mode Reset (DECRST) -> Use Normal Screen Buffer.
|> |
|> |
|> | The reason seems to be that the Debian screen package packages a custom
|> | /etc/screenrc that does not include this explicit term capability:
|> |
|> |
|> | #
|> | # Do not use xterms alternate window buffer.
|> | # This one would not add lines to the scrollback buffer.
|> | termcap xterm|xterms|xs ti=\E7\E[?47l
|> | terminfo xterm|xterms|xs ti=\E7\E[?47l
|> |
|> |
|> |
|> | If I comment these out, my screen issue is resolved.
|> |
|> | I'm not suggesting this is a problem with Cygwin screen... it is using
|> | the upstream settings. In fact, I am not confident to say where the
|> | fault lies. Perhaps screen is right to use these sequences, but the
|> | xterms used (putty and mintty) aren't doing the right thing?
|>
|> yes - that's one of a half-dozen cases where PuTTY has never matched xterm's
|> behavior.
| I've tested the CSI?1049h and CSI?1049l pair on xterm, pterm, mintty and
| see no difference. In what way would it not match? And what are the
I mentioned it here:
https://stackoverflow.com/questions/24613237/terminal-retains-bg-color-after-closing-vim-using-color-scheme-and-putty-256co/37869114#37869114
| cases, do you have a list?
no - I've a few notes which aren't incorporated into the terminal description
https://invisible-island.net/ncurses/terminfo.src.html#tic-putty
offhand, there's differences in wrapping, as well as how modifiers affect cursor-keys.
| Thanks
| Thomas
--
Thomas E. Dickey <dickey@xxxxxxxxxxxxxxxxxxxx>
http://invisible-island.netftp://ftp.invisible-island.net
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple