Open salmonax opened 8 years ago
Woops. It occurs with 0.7.2 and 0.7.1 as well, but I can't figure out why, except that process event messages come into the terminal out of order whenever it happens.
Sleuthed this a little further: the issue starts happening at 0.4.7, which is when the cygwin connector started setting $TERM to 'xterm-256color' instead of 'cygwin.' Changing $TERM manually with 0.4.7 reproduces the problem. Changing $TERM to cygwin in latest versions straightens out the line-jumbling (as does switching to cons25, vt100, etc.) but breaks colors in ssh.
So, why do you think that screen bugs are related to connector or ConEmu?
Simple: because it doesn't happen in native terminals, it doesn't happen in ConEmu without the connector, and it doesn't happen in MinTTY. The meltdown is also fairly egregious; it doesn't happen in Screen, but after Screen is exited, causing all further terminal output to wind up on a single line at the top of the terminal. I would bet that it can be reproduced in another way, but that this just happens to be the one I found. There is something about how the connector works that isn't correctly handling what I suspect to be Bash job control notifications.
Ultimately, if the intention is for POSIX support to be stable, it makes sense to want to know the cases in which normal operation (and pretty unobscure operation, at that) causes everything to break, rather than saying "oh, if Screen broke it, that must be Screen's problem," no?
From what you have described, the problem appears if TERM
is set to xterm-256color
, Isn't it? Also, you have not checked (seems like) the behavior of screen, when TERM
is set to xterm-256color
in mintty.
So, the descsription of the problem is not complete at least.
Anyway, I need exact steps to reproduce and screenshots highlighting the problem.
Good point. I just made sure to try it in MinTTY, and it doesn't do it when TERM=xterm-256color, either. With the connector in ConEmu, it happens for TERM=xterm and TERM=xterm-256color, but not for anything else I tried (vt100, cons25, screen, screen256-color, cygwin)
Hmm, ok. I can't deny that I'm doing something a little obscure (ie. running screen over ssh to a remote linux terminal, then detaching), but the terminal that goes screwy is a bare cygwin prompt, and not wrapped either in SSH or screen, so I think it's sound. I'll spend some time tomorrow seeing what the bare minimum way to reproduce it is and post some shots.
Nice, waiting for them.
From my previous experience, there was problems with
--log
switch which creates log file with raw output received from cygwin. It may help too.Ok, I figured out what is causing it and how to induce it:
That termcapinfo line was something to enable mouse and shift-page up scrolling. It disables an alternate text buffer, according to the Screen FAQ. Since adjusting termcapinfo basically amounts to a hack, I could understand why this wouldn't seem like a critical problem. But hopefully it reveals an implementation quirk?
Sadly, I think I've given up on the connector for now. Glad to see that it exists, though. :-)
Using conemu-cyg-64, cygwin 2.2.1, reproduced with both ConEmu 151207 and 160211, connector 0.7.3 and 0.7.4.. Doesn't cause the issue without Screen, and 7.2 works fine.
Various issues occur: 1) intermittently, "cat AnsiColors256.ans" will draw at the top of the terminal, spilling into a single line and disappearing. This co-occurs with the ssh exit message fixing itself to the bottom of the terminal, rather than appearing above the local prompt. 2) Filling the terminal with text on the SSH+Screen side and exiting will fail to move drawing to bottom and cause overdraw, which didn't occur in 0.7.2