# Space in Terminal Erases Characters



## ComradeSlice (Sep 28, 2020)

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.


----------



## VladiBG (Sep 28, 2020)

Use Putty


----------



## ComradeSlice (Oct 13, 2020)

VladiBG said:


> Use Putty


No thanks. Any other takers?


----------



## kpedersen (Oct 13, 2020)

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.


----------



## ComradeSlice (Oct 13, 2020)

VladiBG said:


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


----------



## ComradeSlice (Oct 13, 2020)

kpedersen said:


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



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".


----------



## VladiBG (Oct 13, 2020)

Yes i realize that and deleted my comment.









						TTY PTY support in Windows OpenSSH · PowerShell/Win32-OpenSSH Wiki
					

Win32 port of OpenSSH. Contribute to PowerShell/Win32-OpenSSH development by creating an account on GitHub.




					github.com
				





ps.
you can change new terminal transparency with ctrl+shift+mouse scroll


----------



## ComradeSlice (Oct 13, 2020)

I also tried running ssh.exe directly, without invoking it from cmd.exe, and the same thing is happening.


----------



## VladiBG (Oct 13, 2020)

open cmd
set TERM=VT100
ssh user@host

own me a beer


----------



## ComradeSlice (Oct 13, 2020)

VladiBG said:


> open cmd
> set TERM=VT100
> ssh user@host
> 
> own me a beer



I'll be damned, that did it. Can you explain how this works and what it does?


----------



## ComradeSlice (Oct 13, 2020)

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"?


----------



## kpedersen (Oct 13, 2020)

Does this work?

```
$ 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.


----------



## ComradeSlice (Oct 13, 2020)

"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".


----------



## VladiBG (Oct 13, 2020)

TTY PTY support in Windows OpenSSH · PowerShell/Win32-OpenSSH Wiki
					

Win32 port of OpenSSH. Contribute to PowerShell/Win32-OpenSSH development by creating an account on GitHub.




					github.com


----------



## kpedersen (Oct 13, 2020)

ComradeSlice said:


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


----------



## decuser (Oct 13, 2020)

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.


----------



## ccammack (Oct 13, 2020)

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.


----------



## ComradeSlice (Oct 13, 2020)

Neubert said:


> 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>."
> 
> ...



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.


----------



## ccammack (Oct 13, 2020)

VirtualBox is the ultimate workaround for Windows problems.


----------



## VladiBG (Oct 13, 2020)

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.


----------



## a6h (Oct 13, 2020)

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!


----------



## kpedersen (Oct 14, 2020)

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.


----------



## a6h (Oct 14, 2020)

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?


----------

