Terminal: Nano cursor move issue with certain characters in line

Created on 12 Sep 2018  路  11Comments  路  Source: microsoft/terminal

Using 1803 here, (but see the same issue with my insiders build at home)

Noticed while editing a _pwsh_ script with _nano_ but observed in other files as well
I'm ssh'd into a SUSE 27 svr from WSL - the issue is not apparent when using nano on WSL locally.
$TERM is xterm-256color

When moving the cursor backwards (to the left), the cursor & text on the screen get wonky.
First the cursor jumps to the beginning of line, then it moves to the far right of screen.

Product-Conhost Resolution-Fix-Available Resolution-Fix-Committed

Most helpful comment

@uSlackr I know this is a bit old but I ran into this today and thought I'd contribute.

I have the same problem with CentOS also using xterm-256color and the capability that seems to cause the problems is cbt (caret back tab).

You can change TERM to something that doesn't support cbt (xterm-color I think?), or you can recompile xterm-256color to remove the cbt capability. I recompiled it and it seems to fix the problem for me.

infocmp > ~/myterm.ti
# edit myterm.ti -- remove the "cbt=\E[Z" entry (rename the term too if you want)
sudo tic ~/myterm.ti
# if you renamed it, make sure to add a line to your .bashrc to change TERM
# export TERM=xterm-256color-nocbt

Hope that helps.

All 11 comments

What's the TERM variable set to on the SUSE machine? (echo $TERM)

While ssh'd into the box, could you paste the output of infocmp?

My first guess is that TERM it's not xterm or xterm-256color.
My second guess is that they're using an updated termcap that's got some new sequence we don't yet recognize.
Thanks!

Sorry. Looked at that and didn't add it. it's: xterm-256color. (Added to original post)

xterm-256color is confirmed. infocmp output attached.

Thanks!

infocmp.txt

@zadjii-msft do you need anything else from me on this?

@uSlackr Not currently, no. I've added it to my bug backlog, I'll investigate more soon.

@uSlackr I know this is a bit old but I ran into this today and thought I'd contribute.

I have the same problem with CentOS also using xterm-256color and the capability that seems to cause the problems is cbt (caret back tab).

You can change TERM to something that doesn't support cbt (xterm-color I think?), or you can recompile xterm-256color to remove the cbt capability. I recompiled it and it seems to fix the problem for me.

infocmp > ~/myterm.ti
# edit myterm.ti -- remove the "cbt=\E[Z" entry (rename the term too if you want)
sudo tic ~/myterm.ti
# if you renamed it, make sure to add a line to your .bashrc to change TERM
# export TERM=xterm-256color-nocbt

Hope that helps.

@arpsmack Thanks for the tip.
I tried removing this "cbt=\E[Z," made sure the comma separators were correct and added -nocbt to the name in the top line. Compiled it, changed .bashrc and logged out/in. Terminal reported
"WARNING: terminal is not fully functional" and nano would not start.
I was able to use vi to revert changes. Not sure what I might have done wrong.

Aw man, sorry to hear that. Perhaps there are other complications from doing it within WSL. I'm SSHing into a vagrant VM running CentOS using the native Windows 10 OpenSSH.

Have you tried changing your TERM to something like xterm-color or linux? I've heard of other people having success with those.

No worries. I manage :-)

I just tried xterm-color and it seems to work! I'll try it for a couple days.

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:
nano-centos

(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).

I'm hoping this was actually fixed in 1809, but another fix for tabstops went in to a recent internal build. If this re-surfaces after #283 hit's Insider's, feel free to re-activate, though I'd probably need more help reproing at that point.

I verified the fix with Insiders 18312.1001. Thanks!

Was this page helpful?
0 / 5 - 0 ratings