Space in Terminal Erases Characters

When I press the space bar or enter characters in the terminal it does not push any characters to the right of the cursor it simply draws over them. The characters are still in the buffer they're just not rendered. For example if I type in "nnn" in the terminal, move the cursor all the way to the left, and then type in "mmm" all of the "n"s will be erased but if you press Enter it will show "mmmnnn". I want the terminal to push the characters to the right when typing additional characters. Any ideas? I'm using the version of OpenSSH that comes with Windows 10.
 
I see this issue very commonly in the cmd.exe (not just for ssh) so I assumed it was just yet another bug Microsoft is never going to fix because they cannot monetize it.

You might want to try out a less legacy terminal. Perhaps the official one that is set up to replace cmd.exe one day:
https://github.com/microsoft/terminal

If you run tmux within the terminal, does that solve any issues? This "terminal in a terminal" usually fixes a lot of issues for me.
 
Change your console setting to be in UTF with modern terminal not the legacy. In legacy console the behavior that you are describing is the same.
View attachment 8591
I changed the codepage to 65001 and legacy console is not turned on, but it's still overriding the characters. In cmd.exe itself it doesn't do this, only in ssh.exe. For example, let's say in SSH the buffer currently contains "foo". If I move the cursor to the beginning and type "bar" it will erase "foo" but when I press enter the command will have been "barfoo". It's not really erasing the characters, it's just not shifting them to the right as I type additional characters.
 
I see this issue very commonly in the cmd.exe (not just for ssh) so I assumed it was just yet another bug Microsoft is never going to fix because they cannot monetize it.

You might want to try out a less legacy terminal. Perhaps the official one that is set up to replace cmd.exe one day:
https://github.com/microsoft/terminal

If you run tmux within the terminal, does that solve any issues? This "terminal in a terminal" usually fixes a lot of issues for me.

I just tried out the Windows Terminal and the same thing is happening. It's not erasing the characters in the terminal itself it's only doing it in SSH. You can see in this image if I move the cursor to the left of "foo" and type "b" it will render "echo boo", having erased the "f", but the buffer actually contains "echo bfoo".

OpenSSH Buffer.png
 
When I set TERM to VT100 the "clear" command no longer functions. I get "tput: tgetent failure: No such file or directory". Do you know a way to fix the character erasing issue without also breaking "clear"?
 
Does this work?
Code:
$ TERM=xterm clear

You could alias clear='TERM=xterm clear'

I am guessing using the old vt100 terminal standard reduces the amount of features that causes the Windows cmd to choke. Unfortunately one of those features was a requirement for clear to work. <ctrl>+L probably wont clear the screen either.
 
"man" gives me "WARNING: terminal is not fully functional". If you explain what TERM=VT100 does maybe I can figure out how to fix the erasing issue without breaking the rest of the terminal.

Setting TERM="xterm clear" from Windows and then invoking OpenSSH also fixes the character erasing issue but it still gives me "terminal is not fully functional" and "tgetent failure".
 
Setting TERM="xterm clear" from Windows and then invoking OpenSSH also fixes the character erasing issue but it still gives me "terminal is not fully functional" and "tgetent failure".

Ah sorry for not being clear (pun not intended). What I meant is instead of running clear and getting those tgetent errors; instead run TERM=xterm clear. This should specify the terminal type temporarily just whilst you attempt the clear command.
 
ComradeSlice if you're married to cmd/powershell (the default shell on windows that runs ssh, if you don't specify anything else), I can't offer much by way of advice. However, if you are open to using a more useful terminal, the simplest by far is just download git-scm and let it install the *nix utilties including git-bash, which is bash on windows. That shell will work as advertised and additionally perform well as a vt-100 if you so desire.
 
I don't like PuTTY either, but its terminal emulation has always worked better than anything else for me. I have not installed Windows 10 yet, so the new WSL stuff might work better.

If you only have a few machines to manage, use the PuTTY dialog to create and save a config for each machine, then install Cmder and create Settings|Startup|Tasks to assign hotkeys to launch each config with the command "Putty.exe -load <machine-config>."

If you also use ssh-keys, you'll never even see the PuTTY dialog again unless you need to add a new config. Use ssh-keygen to create them, then import them into PuTTYGen to translate the private key into PuTTY's format and save it as putty.ppk. Keep the original key files in case you find a way to dump PuTTY and switch to ssh later on.

Add a shortcut to your Windows Startup folder that runs ""C:\Program Files\PuTTY\pageant.exe" "C:\Users\<user>\.ssh\putty.ppk"". When you log in, it will ask for the password to decrypt the private key. Run Cmder and enter the hotkey to log into each machine with a working terminal.

I hate that it's non-standard but the terminal works very well. If you find something that works for you, please come back and report what you did so I can copy it.
 
I don't like PuTTY either, but its terminal emulation has always worked better than anything else for me. I have not installed Windows 10 yet, so the new WSL stuff might work better.

If you only have a few machines to manage, use the PuTTY dialog to create and save a config for each machine, then install Cmder and create Settings|Startup|Tasks to assign hotkeys to launch each config with the command "Putty.exe -load <machine-config>."

If you also use ssh-keys, you'll never even see the PuTTY dialog again unless you need to add a new config. Use ssh-keygen to create them, then import them into PuTTYGen to translate the private key into PuTTY's format and save it as putty.ppk. Keep the original key files in case you find a way to dump PuTTY and switch to ssh later on.

Add a shortcut to your Windows Startup folder that runs ""C:\Program Files\PuTTY\pageant.exe" "C:\Users\<user>\.ssh\putty.ppk"". When you log in, it will ask for the password to decrypt the private key. Run Cmder and enter the hotkey to log into each machine with a working terminal.

I hate that it's non-standard but the terminal works very well. If you find something that works for you, please come back and report what you did so I can copy it.

I've used pageant before with a shortcut in HKCU:\Software\Microsoft\Windows\CurrentVersion\Run that adds the key. I know PuTTY is superior but I've had problems there as well. The default settings don't render borders in ports' menuconfig properly and there's other little rendering issues like that. My goal was to set up my profile to work with my terminal without having to modify anything on the client side.
 
In order to render the console properly the remote character set must match with the lang of your shell. It's not only for the PuTTY but for all remote terminals.
1602612247038.png
 
I run WSL2 for shell-y jobs in Windows. It works. I don't like the PuTTy either. It's creepy. In the past, before WSL, the only solution was "ConEmu". AFAIR It was open source with a unintuitive setting window, be warned!
 
I have just tried this now. Indeed the windows cmd screws up a little. The biggest is in the vi editor, unless you are on the top line it doesn't refresh properly when you delete a line 'dd'.

My solution is run tmux (which I generally run anyway). Then TERM env variable is set to 'screen' automatically and this works for pretty much everything I tested with.
 
There's at least two solutions: Putty and tmux. I didn't mention ConEmu anymore, because I haven't tested it recently.
Now what's the reason behind this mess, aka scrambled movement of cursor?
 
Back
Top