Spurious control codes render "make nconfig" for Linux Kernel sources unusable (ncurses related?)

[GoogleCodeExporter]

Steps to reproduce:
1. use mintty to connect to a box with linux kernel sources over SSH
2. use "make nconfig" to bring up ncurses-based config menu
3. start scrolling around with the arrow keys, rapidly.

Behaviour:
Obviously, you should be able to scroll around without issue, instead you get 
flipped backward out of menus, nconfig thinks you want to exit and other 
nonsense. The behaviour seems to worsen the longer mintty has been running.

I am running mintty 1.1.2 and latest Cygwin as of 25-12-2012

Original issue reported on code.google.com by oli...@gmail.com on 25 Dec 2012 at 8:49

[GoogleCodeExporter]

This kind of behaviour is likely to be caused by a slow remote connection which 
splits up escape sequence (like those of cursor keys). Please try with another 
terminal to compare.

Original comment by towom...@googlemail.com on 28 Dec 2012 at 2:59

[GoogleCodeExporter]

As a result of this issue, I've been falling back to using PuTTY, which does 
not exhibit the behaviour

Original comment by oli...@gmail.com on 28 Dec 2012 at 6:14

[GoogleCodeExporter]

I agree with towo, this is likely due to escape sequences being split up on the 
way. This would mean it's a bug in the remote application, in that it shouldn't 
rely on escape sequences to arrive in one piece. In any case, mintty writes 
escape sequences to the underlying pseudo terminal (pty) device in one piece, 
so then it's up to the Cygwin DLL as well as the SSH client and server as to 
how they arrive at the other end.

PuTTY doesn't use the Cygwin DLL and contains its own SSH client, so maybe that 
does something to ensure that escape sequences arrive in one piece. Or maybe 
it's just lucky. In any case, the more pertinent comparison would be with other 
pty-based Cygwin terminals such as rxvt, xterm, or PuTTYcyg.

Original comment by andy.koppe on 3 Jan 2013 at 11:11

• Changed state: Waiting

[GoogleCodeExporter]

I've now tried invoking the Cygwin SSH binary directly from a standard windows 
DOS-style prompt.

When using Cygwin's SSH in this way, it also functions without issue, so that 
rules out it being SSH itself, and presumably cygwin's libs?

Original comment by oli...@gmail.com on 14 Jan 2013 at 11:28

[GoogleCodeExporter]

Hi!

Same happens when I'm using mintty. From mintty console I ssh into a linux 
server and I run tmux there. What I see is that Ctrl+b+arrow is not working. 
From putty I dont see any issues, so now I'm using putty. This is the only one 
reason I'm using putty instead of mintty.
I also tried from DOS-style prompt and it was OK.

Original comment by szev...@gmail.com on 25 Jan 2013 at 12:15

[GoogleCodeExporter]

I've also tried with tmux now. Either mintty+ssh or cmd+ssh, behaviour is the 
same here.
What is Ctrl-b arrow supposed to do? What exactly do you get?

Original comment by towom...@googlemail.com on 7 Feb 2013 at 7:21

[GoogleCodeExporter]

Ctrl B is the Tmux equivalent of Screen's Ctrl A - after specifying Ctrl+B, you 
use the arrow keys to switch between panes.

Original comment by oli...@gmail.com on 7 Feb 2013 at 9:59

[GoogleCodeExporter]

Yup, this is definitely something specific to mintty. I've a similar issue with 
mintty + ssh + tmux.
I cant find a way to use the scrollback buffer inside a tmux window (PageUP 
PageDown won't work),
also as mentioned above Ctrl+[Arrow] sequences do not work. This works 
perfectly within a Cygwin
(using default cmd.exe for console) + SSH + tmux (not that in both the cases 
the remote server
has the same settings for bash - .inputrc, .bashrc and .tmux.conf)

Original comment by jayasimh...@gmail.com on 15 May 2013 at 2:26

[GoogleCodeExporter]

I had meanwhile reproduced the problem with tmux on a remote ppc (sorry for not 
reporting earlier). Right now I could also reproduce the problem with xterm 
(+ssh+remote tmux). So as Andy suggested, it's not a mintty issue. More likely, 
it's a problem of the cygwin pty handling.

Original comment by towom...@googlemail.com on 28 May 2013 at 9:53

[GoogleCodeExporter]

Does anyone has found a workaround for this?

Original comment by jayasimh...@gmail.com on 27 Jun 2013 at 10:34

[GoogleCodeExporter]

I've been hitting this most frequently while using tmux on a remote host 
connected via Cygwin's ssh inside of a local mintty.  Even just a simple "ls 
-alF<enter>" will end up with "ls -alF;2u" on the command line and no actual 
carriage return.  But I've also had problems with arrow keys and inadvertently 
issuing undo a lot in vim inside tmux in the same configuration.

I tend to be typing fairly quickly whenever this kind of things happens.  I'm 
not sure if that has anything to do with the problem.  But it does seem to 
correlate that the faster I'm issuing keystrokes, the more likely the problem 
occurs.

Original comment by mrnipper on 27 Jun 2013 at 6:50

[GoogleCodeExporter]

And to reply to myself, I just realized that speed is in fact part of my 
problem here.  It's because I still have the shift key partially down when I 
hit enter that I'm getting the ";2u" instead of a carriage return.  And this 
particular problem only happens inside a tmux window.  "shift+enter" outside of 
tmux still produces a normal carriage return inside a remote shell using 
mintty.  But inside tmux, it produces the ";2u".  So I'm not sure if this is 
actually even related to this bug!

A reminder to type more cleanly I guess.  Having said that, the arrow keys 
undoing things in vim is still rather annoying.  I guess I should get more 
accustom to using the letter keys for movement.  :)

Original comment by mrnipper on 27 Jun 2013 at 6:58

[GoogleCodeExporter]

Referring to http://cygwin.com/ml/cygwin/2013-09/msg00042.html ,
although it's a different issue, I was just wondering whether something like
set -g escape-time 100
would help.

Original comment by towom...@googlemail.com on 5 Sep 2013 at 1:29

[GoogleCodeExporter]

Using tmux 1.4, this didn't help much. Still can't use my scroll back buffer 
(ie., 'Ctrl+b [' and arrow keys doesn't scroll back or forth, rather exits the 
copy mode).

Original comment by jayasimh...@gmail.com on 5 Sep 2013 at 2:47

[GoogleCodeExporter]

Please retest with cygwin 1.7.34-6 which fixes an issue that might well be 
related to this one. (Cf. 
https://cygwin.com/ml/cygwin-developers/2014-11/msg00000.html)

Original comment by towom...@googlemail.com on 4 Feb 2015 at 6:28

[GoogleCodeExporter]

The fix is now in the main release 1.7.35 and might close this issue. Please 
retest.

Original comment by towom...@googlemail.com on 5 Mar 2015 at 9:12

[GoogleCodeExporter]

Answered on https://github.com/mintty/mintty/issues/366

Original comment by towom...@googlemail.com on 22 Jun 2015 at 2:24