Odd caret/cursor behavior in nano within SSH session

[ShimShamSam]

A brief description

When SSH'd into a server and editing a file in nano, moving the caret around with the arrow keys or deleting text is buggy. I've attached a gif below demonstrating the issue.

This does not happen if you're not SSH'd into a server, giving me reason to believe this something to do with the way SSH state is managed.

A corresponding Uservoice suggestion already exists.

Expected results

The caret should move around as expected

Actual results (with terminal output if applicable)

The caret moves all over the place.

Your Windows build number

14971

Steps / All commands required to reproduce the error from a brand new installation

1. SSH into a server

2. Create a file with the following lines of text:

   This is a test.
   I'm going to press backspace to delete this text.

3. Open the file in nano

4. Move the caret to the end of the file

5. Press and hold backspace

[adamcantwell]

I can also replicate this issue. It has been present since very early releases.
I am replicating it on build 14971 into a CentOS 5.11 server running Nano 1.3.12.

[aseering]

Hm, very interesting.

I cannot replicate this issue on the servers that I access regularly; I've never seen it before. I am currently trying to replicate it ssh'ing into an Ubuntu 16.04 server running Nano 2.5.3. I use ssh frequently, but mostly to systems running more-recent userspace tools.

I wonder if the incompatibility isn't ssh; I wonder if the older version of nano does something that WSL doesn't support yet?

[fpqc]

Your remote terminfo might be defective?

[adamcantwell]

I just did a little more testing and confirmed that the issue is not present under Ubuntu 16.04.1 and nano 2.5.3. Perhaps it is an issue with older distros / editors aseering suggested.

[aseering]

I just downloaded nano 1.3.12 from the CentOS archives and ran it locally on WSL. I was not able to reproduce this issue. So it must be a little more complicated than just "old nano binaries".

[fpqc]

@aseering you need to mask the ubuntu terminfo file with the centos one.

[aseering]

@fpqc does that then reproduce the issue? Do you also need the old binary, or is it just the CentOS terminfo file?

[fpqc]

@aseering I haven't tested it but this sounds 100% like an incompatible terminfo file.

[zadjii-msft]

I wasn't able to repro this with my Windows=14981->Ubuntu,nano=15.10, 2.4.2 ssh connection. Do we have a repro on a ssh to Ubuntu? Or is this only happening on connections to CentOS machines?

[ShimShamSam]

I can confirm that the servers I SSH into when experiencing this error are running CentOS

[fpqc]

@ShimShamSam does it happen with 7.0?

Also, on your CentOS instance, could you do me a favor and do this:

infocmp $TERM >terminfo.src and post the source?

[CherryDT]

I get this behavior on Amazon EC2 instances running Amazon linux all the time:
uname -a: Linux xxxxx 4.4.23-31.54.amzn1.x86_64 #1 SMP Tue Oct 18 22:02:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nano --version: GNU nano, version 2.5.3

It does not happen on an older server running Debian 7.10:
uname -a: Linux xxxxx 3.2.0-4-amd64 #1 SMP Debian 3.2.82-1 x86_64 GNU/Linux
nano --version: GNU nano version 2.2.6 (compiled 21:40:01, Jun 22 2012)

[fpqc]

@CherryDT Again, could you do an infocmp in a broken terminal when you're ssh'd in? This sounds like a missing terminfo file.

[ShimShamSam]

@fpqc CentOS release 6.7 (Final)

#       Reconstructed via infocmp from file: /usr/share/terminfo/x/xterm
xterm|xterm terminal emulator (X Window System),
        am, bce, km, mc5i, mir, msgr, npc, xenl,
        colors#8, cols#80, it#8, lines#24, pairs#64,
        acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=^M,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
        cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
        dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
        flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
        ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
        ind=^J, indn=\E[%p1%dS, invis=\E[8m,
        is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
        kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
        kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=\177, kcbt=\E[Z,
        kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
        kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
        kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
        kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
        kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
        kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
        kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
        kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
        kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
        kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
        kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
        kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
        kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
        kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
        kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
        kf58=\E[21;3~, kf59=\E[23;3~, kf6=\E[17~, kf60=\E[24;3~,
        kf61=\E[1;4P, kf62=\E[1;4Q, kf63=\E[1;4R, kf7=\E[18~,
        kf8=\E[19~, kf9=\E[20~, khome=\EOH, kich1=\E[2~,
        kind=\E[1;2B, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        kri=\E[1;2A, mc0=\E[i, mc4=\E[4i, mc5=\E[5i, meml=\El,
        memu=\Em, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
        rin=\E[%p1%dT, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l,
        rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m,
        rmul=\E[24m, rs1=\Ec, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
        setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
        setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
        setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
        sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
        sgr0=\E(B\E[m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h,
        smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m,
        smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
        u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,

[fpqc]

@ShimShamSam Yeah, I did a diff with the version I have on Arch, and it's a bit different. Here's the diff:

10,18c10,18
<         cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
<         dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
<         flash=\E[?5h$<100/>\E[?5l, home=\E[H, hpa=\E[%i%p1%dG,
<         ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
<         ind=^J, indn=\E[%p1%dS, invis=\E[8m,
<         is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~, kEND=\E[1;2F,
<         kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~,
<         kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=\177, kcbt=\E[Z,
<         kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
---
>         cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
>         dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
>         el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
>         hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
>         il=\E[%p1%dL, il1=\E[L, ind=^J, indn=\E[%p1%dS,
>         invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
>         kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
>         kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, kb2=\EOE, kbs=^H,
>         kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
40,43c40,44
<         rin=\E[%p1%dT, rmacs=\E(B, rmam=\E[?7l, rmcup=\E[?1049l,
<         rmir=\E[4l, rmkx=\E[?1l\E>, rmm=\E[?1034l, rmso=\E[27m,
<         rmul=\E[24m, rs1=\Ec, rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7,
<         setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
---
>         rin=\E[%p1%dT, ritm=\E[23m, rmacs=\E(B, rmam=\E[?7l,
>         rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>,
>         rmm=\E[?1034l, rmso=\E[27m, rmul=\E[24m, rs1=\Ec,
>         rs2=\E[!p\E[?3;4l\E[4l\E>, sc=\E7, setab=\E[4%p1%dm,
>         setaf=\E[3%p1%dm,
46,50c47,52
<         sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
<         sgr0=\E(B\E[m, smacs=\E(0, smam=\E[?7h, smcup=\E[?1049h,
<         smir=\E[4h, smkx=\E[?1h\E=, smm=\E[?1034h, smso=\E[7m,
<         smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
<         u8=\E[?1;2c, u9=\E[c, vpa=\E[%i%p1%dd,
---
>         sgr=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p5%t;2%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m,
>         sgr0=\E(B\E[m, sitm=\E[3m, smacs=\E(0, smam=\E[?7h,
>         smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=,
>         smm=\E[?1034h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
>         u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
>         u9=\E[c, vpa=\E[%i%p1%dd,

[aseering]

@fpqc , I'm not familiar with how terminfo files work. Any chance you could give a quick summary of what this means and what to do about it? (My initial interpretation is that these other platforms use different control sequences to perform some actions, in particular, sequences that the Windows console doesn't implement correctly yet?)

Also, would it be correct/useful to pipe the output above through sed 's/, /,\n/g' before doing diff? (Is there significance to which thing is on which particular line, or is it just a giant long list that's being wrapped?) It looks to me at first glance like a lot of the individual entries in even the diff above are the same; just, sometimes there's an extra entry in one that affects the line wrapping, causing many subsequent lines to differ. So if you split by line, you'd get a smaller diff.

[fpqc]

@aseering The control sequences tell the terminal or terminal emulator what to do and are specific to those pieces of hardware or software (possibly in different modes). Terminfo (and earlier Termcap) provide something like a translation layer that translates, for example, the control sequence to move the caret left or right to a specific control sequence for the terminal.

This means an application writer can say "move the cursor left/right)", which then queries the terminfo for $TERM how to translate that control into the appropriate control sequence.

An old, outdated, or otherwise buggy or broken terminfo database will not match the controls with the correct control sequences and will therefore output and receive broken or even garbage controls.

[aseering]

@fpqc -- thanks for the summary! I guess what I'm specifically looking for is, why would terminfo failures be relevant to WSL-specific display corruption?

[fpqc]

@aseering Because when you use ssh, it uses the terminfo on the remote machine rather than on the local machine, which could lead to a mismatch in version between the client vterm, which runs locally, and the remote terminfo, which exists on the remote machine.

[ShimShamSam]

@fpqc Ultimately this is an issue with WSL, right?

[fpqc]

@ShimShamSam I sort of doubt it, but it is highly complex and depends on the exact xterm mode that WSL is emulating (iirc xterm can emulate over 20 different physical terminals). Perhaps I could be wrong, but you have there that there is a material difference between the local and remote terminfo files.

I had this exact problem when sshing into a FreeBSD VPS from a Linux box, and the problem was terminfo.

Another possibility is that there is a failure to set modes (possibly due to an older breaking change with ncurses (ncurses4, ncurses5, and ncurses6 are all mutually binary incompatible, and WSL may only implement the newer sequences while ignoring the older ones)).

[ShimShamSam]

@fpqc Git Bash on Windows works fine, as does PuTTY, so I'm inclined to think this should be the responsibility of WSL to fix. Furthermore, this primarily seems to happen in Nano, not Vim.

[aseering]

@fpqc -- I agree with @ShimShamSam -- if I can ssh from an Ubuntu Linux machine into a CentOS server and it works fine (which seems to be the case for me), and I can ssh from WSL into a CentOS server and the terminal is corrupted (as is described here -- ditto for environments other than CentOS), then fundamentally this is something where WSL needs to fix itself to behave more like Ubuntu. As far as I'm concerned, the question is, exactly what does WSL need to do?

[fpqc]

@aseering Not having an affected centos instance to ssh into, I don't know. If it were a problem with WSL, we should see the behavior locally or when SSHing into a Centos7 instance at least. The fact that it is dependent on the distro of the remote machine makes it very odd and likely to be related to Terminfo.

[zadjii-msft]

@fpqc @aseering @ShimShamSam I think to summarize what everyone's saying:
It's probably a conhost issue not behaving properly with that CentOS version of the xterm terminfo. That diff is real hard to look at, but I'll try and see if anything jumps out.

I'd say it's highly unlikely that this is a problem with the WSL kernel itself, as this is code emitted from a remote machine not running the WSL kernel, so it could only really be a conhost problem.

[ShimShamSam]

@zadjii-msft By "conhost", you mean "conhost.exe", right? If so, where should we report this bug?

[fpqc]

@ShimShamSam Zadjii is the guy who is going to go into the code and fix it. He's one of the programmers on the console/conhost team. Basically reporting this kind of thing, for now, is best done here. Eventually they will have their own repo.

[zadjii-msft]

@ShimShamSam I crawled through those terminfos, and nothing looks particularly out of the ordinary or misconfigured.

Does the behavior repro in Putty? It may be a bug with backspace itself. Does it only happen in nano, or are there other applications (vim, emacs) that the behavior also occurs in?

[ianling]

I'm running into a similar issue again.

Windows 10 build 14393, my apt packages are up-to-date within the Linux subsystem. Nano works fine when used locally, but when I SSH to an up-to-date Debian stable box with Nano 2.7.4, if I hold down an arrow key to scroll through a long file, it will seemingly randomly write A, B, C, or D into the file, depending on which arrow key I'm holding.

I've tries launching Bash through cmd and through ConEmu, and both exhibit this issue, even after switching ConEmu between XTerm and AppKeys escape sequences. When I SSH to this server using Putty, I do not get this issue.

Since I don't experience the issue with nano locally, and I don't experience the issue when using Putty, it looks like the issue must be with how WSL handles the SSH connection.

None of the solutions above my comment help (the two commands directly above my comment, and updating the terminfo on the remote host).

[aseering]

Hi @ianling -- build 14393 contains the very first public-beta release of WSL; it has gone through several major releases and a lot of console bugfixes since then. Would you be willing to update to the latest stable Windows release (build 16299, I believe) through Windows Update? And try again, see if it resolves the issue for you.

[ianling]

I figured that was probably the issue when I noticed I was on 14393. It's a corporate environment and I don't manage WSUS here, so I'm probably out of luck unfortunately. Thanks for the response!

[MaxDiOrio]

So this issue is actually with CentOS/RHEL then it seems, not WSL correct? I'm experiencing it when SSH'ing into a RHEL 7.4 server that's fully updated via yum. It only impacts nano, not console, vi, or anywhere else.

Sounds like the solution is downloading a new terminfo source and merging it in - which I'll have to script on all our Linux servers.

[MaxDiOrio]

And to follow up, I did the following on an impacted RHEL 7.4 server, exited the ssh session, exited the WSL window, reconnected and it still is doing the cursor thing. Does the remote server need to be restarted or sshd restarted after applying the terminfo update?

wget http://invisible-island.net/datafiles/current/terminfo.src.gz
gzip -d terminfo.src.gz
tic -sx terminfo.src

[NothingWeAre]

https://serverfault.com/questions/329154/ssh-garbling-characters-in-vim-nano-on-remote-server
While this is not related to windows, provided answer may point to potential issue.
As additional evidence that this may be related I can say that executing export TERM=xterm-color seems to fix issue in my case

[bitcrazed]

Thanks for the discussion.

Closing this issue since:

1. This issue doesn't look to be WSL/Console related
2. This is the WSL issues repo, but this is an issue in Console which has its own Console GitHub Repo
3. GitHub doesn't allow issues to be moved between repos, preserving posters' identity :(

If you have further asks/issues, please file new issues on our Console GitHub Repo.

[Sam-Hall]

Here's the workaround I'm using. Place this function at the end of your ~/.profile to automatically run these commands on any server you ssh into...

# This ssh alias function resolves a issue running nano within an ssh session
function ssh(){
  /usr/bin/ssh -t ${@:1} "stty sane; export TERM=linux; bash"
}

You could also try using the RemoteCommand ssh_config directive, but some servers may not support it.

Just remember that if you want to use the ssh command to setup a tunnel or do anything other than start a terminal session, you'll want to run the ssh binary with the full path to bypass this function (i.e. /usr/bin/ssh).

[nitrologic]

I was really hoping the sane thing would help Sam-Hall. It didn't for me :(

Using nano with the malfunction as described in this issue is serious. Please fix soon.

[Sam-Hall]

I've found that running "export TERM=linux" before running Nano helps a lot more than the "stty sane" command. I really think this issue is a problem with Nano as the link posted by @NothingWeAre suggests.

[nitrologic]

This seems to be heart of my problem - microsoft/terminal#214

[zadjii-msft]

No promises, but this might be related to microsoft/terminal#283 actually. While we only recently regressed this for Ubuntu et al, it might shed some light on this thread as well, as the symptoms seem to be incredibly similar.

[zadjii-msft]

Okay, I've finally gotten some time to try and look at this.

I've got a CentOS 7.6 VM.
I'm connecting to it via WSL+Ubuntu, using ssh
I've got nano 2.3.1.
My Windows build is 18295, which is probably irrelevant - I'm a few weeks of console fixes ^{(and breaks)} ahead of the equivalent Insider's build #.

This looks fine to me:

(admittedly, there's a coloration bug I'm working on in another branch currently that's causing the header/footer to be the wrong color, but that's unrelated)

[nitrologic]

Hi try the following copy and past these 3 lines

Sat Dec 1 13:04:59 2018 +1300 doh
diff --git a/sparky/salesforce/rest.py b/sparky/salesforce/rest.p
index ff4af8a..dc14cdf 100644

move cursor to line 3, left arrow once to get to end of line 2, hit backspace

for me the cursor end up at beginning of line

[Sam-Hall]

All I can say for a fact is that I work with a lot of RHEL servers, versions 6 and 7 mostly. Without the workaround I can consistently reproduce the issue by opening a text file with many lines of text, they don't have to be particularly long lines. Navigating around the file using cursor keys, page up/down and home and end for a bit, then use the cursor left from the beginning of a line to end up at the end of a longish line of text, then backspace a few times and the bug is reproduced.

Since creating an alias for my ssh command that immediately applies "stty sane; export TERM=linux;" I've not experienced the issue. Since it takes a few years for such obscure bugs to get fixed upstream and then a few years later for the fixes to work their way into all the various distros, I'm pretty sure I'm going going to have to get comfortable with this workaround for now.

[therealkenc]

stty sane; 

Thas part does nothing (or at least, shouldn't). Your ssh session pty starts off life sane.

export TERM=linux;

That part is, unfortunately, not WSL actionable. WSL does not control your termcap(5) database.

Follow microsoft/terminal#283 and hope for the best. It only flipped to fix-inbound two days ago and hasn't even hit the street yet.

[zadjii-msft]

@nitrologic Out of curiosity, what about that particular selection of text made you think that nano would be broken for that text, while fixed in the case I previously demonstrated?

There was another internal bug that I would say was pretty similar to this one. I determined the fix for that one was checked in about 2 weeks ago. It's on it's way to Insider's now, so it'll probably first be available around Christmas/New Years, depending on how fast code moves over the holidays.

[nitrologic]

@zadjii-msft with recent update to 1803 (build 17134.471) I am no longer suffering from this issue. Hurrah!

[avielc]

I'm still suffering from that case,
the only workaround i managed to help me was export TERM=eterm-color
i'm on 1809 and still suffers from that. xterm-256color doesn't seem to cut to it
Here is an example of how it looks like on my windows 10 1809 17763.253
connecting to centos 7.6.1810

I do have to point out this didn't happen on Debian system i sshed into.
So something to do with centos<->wsl

I tried to update the terminfo according to the wget command, but it didn't help
the only solution was changing TERM variable

Would love to hear anyone's thoughts or help about it.
Thanks

[nitrologic]

Was fixed now broken again :)
Windows 10.0.17763

[rymo]

Yet Another Workaround for those of us stuck on on old build: add this to the end of your local ~/.ssh/config to avoid editing the .bashrc of every remote box you need to touch:

Host *
  RequestTTY force
  RemoteCommand export TERM=xterm-color && $(echo $SHELL)

[cawoodm]

I have this issue using ConEmu on Windows 10 when I start bash (not sure if this is WSL or git bash to be honest but I think the former) and then ssh into CentOS 7.7. Nano becomes basically unusable at speed - if one types slower it can be mitigated.

[zadjii-msft]

@cawoodm There was actually another issue that was also causing troubles with ssh & centos, and likely also caused problems in ConEmu.

I'd refer back to microsoft/terminal#1825, which tracked the upstream issue.

It should be resolved in the next Windows release ☺️

[cawoodm]

@rymo fixed it for me with ConEmu - thumbs up!

[Markkyboy]

My 2 penneth, for information sake; I had to add export TERM=xterm-color to my .bash_profile - admittedly, this is for SailfishOS.

Thanks to who actually gave this valuable answer, it's been a frustration for years on my device!

[jlorquin]

Yet Another Workaround for those of us stuck on on old build: add this to the end of your local ~/.ssh/config to avoid editing the .bashrc of every remote box you need to touch:

Host *
  RequestTTY force
  RemoteCommand export TERM=xterm-color && $(echo $SHELL)

This did it for me. Thanks a lot.

[YvesR]

Started worked with Windows Server Core and use OpenSSH as it works nice now. But with need of an editor and already use nano on mac and linux I loved to use nano here as well. So I installed using choco install nano but sadly found out that cursor movement do not work properly here (Using Terminal from Mac in a ssh session).

I tried to add

Host *
  RequestTTY force
  RemoteCommand export TERM=xterm-color && $(echo $SHELL)

But getting error for RemoteCommand as export is not compatible on Windows Servers.
Tried to replace with set, but then get other error. Anyone made this work?