Bitvise SSH Server putting extra spaces in session

Question

I am using Bitvise SSH Server on my Windows machine for remote access. The login shell is ZSH, and I am using Oh My Zsh with it. However, I have also tried BASH and got the same problem. Therefore I guess this problem is with Bitvise SSH Server, not my Cygwin shells or the client-side terminal emulators.

The problem can be noticed on the prompt of my ZSH. As long as my SSH session go through this Bitvise SSH Server, there will be some extra spaces in the prompt. Please see the screenshots:

This windows is the MinTTY on that Windows machine. When I open it you can see there is only one trailing space after ~ (before I type ssh 127.0.0.1). However once I SSH-ed into the same machine, there are two trailing spaces after ~ in the prompt. Also, if I do another SSH session (to the tiger machine) within the Bitvise SSH session, the prompt of the second one is also having extra spaces (red underlined prompts). However if I exit from the Bitvise session and SSH to tiger, directly, the prompt is normal (green underlined prompts).

I observed the same thing when connecting from some remote machine (using gnome-terminal or xfce4-terminal as the terminal emulator) to that Windows machine.

Therefore, my conclusion is, the terminal emulator is not to blame for this. The Cygwin and its ZSH are not to blame either, because everything looks good as long as I don't go through Bitvise.

My assumption is there's some special character defined in the Oh My Zsh theme that is not processed correctly when passing through Bitvise. However I couldn't find out what that is exactly. The Oh My Zsh themes look good locally without a Bitvise SSH connection, and they look good on all Linux machines I have. Therefore I think it should be something with Bitvise.

---

As suggested in the comments, I ran set in both environments, and got the outputs dumped into two text files: bitvise.txt and local.txt. Now the biggest issue is I cannot compare them using diff because diff claims they are binary files (and they differ). I am not sure if this has something to do with the weird spaces.

Forcing LANG on diff didn't help.

$ diff -uN bitvise.txt local.txt
Binary files bitvise.txt and local.txt differ

$ LANG=en_US.UTF-8 diff -uN bitvise.txt local.txt
Binary files bitvise.txt and local.txt differ

$ LANG=C diff -uN bitvise.txt local.txt
Binary files bitvise.txt and local.txt differ

The two files are uploaded here: https://drive.google.com/open?id=0B6Pxoys5MF0Bc1d6QUMweUkybHc

---

Tested some different TERM settings... Didn't seem to do anything good. Setting TERM=linux resulted the same with xterm.

---

Updated on 5/23/16

The problem seems to be harder than I expected. I found a folder "C:\Program Files\Bitvise SSH Server\TermInfo" which contains the terminal info files. I replaced the files in that folder with the similar files I copied from a normal Ubuntu machine, but didn't help. I also tried the "cygwin" term info that is installed with Cygwin, no luck... Actually the "cygwin" file that comes with Cygwin is the same with the one that comes with Ubuntu...

I run out of idea now.

When I SSH into the Bitvise SSH Server, I can do exec /bin/bash to replace the current session with Bash. However in that Bash, if I SSH into some other Linux machine that uses Zsh and Oh My Zsh, the same problem persists.

Answer 1

One possibility is that Oh My Zsh renders Unicode characters, and that the issue is that those characters have different widths in a Windows console.

For example, a character that has width 0 in MinTTY might have width 1 in the Windows console, and would advance the cursor. Or a character that has width 1 in MinTTY might have width 2 in the Windows console.

In the screenshots you've provided, you're looking at zsh with "Oh My Zsh" under MinTTY.

But what about in a Windows console? How does Oh My Zsh look there?

Bitvise SSH Server runs your terminal shell in a hidden Windows console, which is necessary to be able to run Windows console programs. Due to this architecture, zsh has to look right in a Windows console in order to render properly via Bitvise SSH Server.

Answer 2

Four weeks later I finally figured out the problem myself. Thanks to denis bider who seems to come from the support team of Bitvise SSH Server. His explanation of on how Bitvise runs shells in Windows console is the key to solve this problem.

It turned out the $TREM environment variable and terminfo files are irrelevant.

The problem I actually had was, the Oh My Zsh themes I am using have characters that are displayed in other ways in my Windows console. However, I found that it was actually because my Windows console code page is set to 936 (Simplified Chinese) because of my Windows local settings (for non-Unicode characters). I found that if I manually change my code page to 437 (U.S. English) in the Bitvise SSH session, the output becomes correct.

Then I realized that for U.S. users, they don't even have this problem at all!

Therefore, the solution is to set the default code page of the Bitvise SSH Windows console to 437. This can be done in Registry, more specifically, in key HKCU\Console\Bitvise toterms.exe, there is a CodePage to be set to 437 (decimal). I also removed FaceName because it doesn't sound necessary at all.

However, setting this alone is not enough, because I found everytime a Bitvise SSH session starts, the value is set back to 936. Therefore, I need to change permissions of HKCU\Console\Bitvise toterms.exe to deny writing access from Everyone. Steps: 1. Right click on "Bitvise toterms.exe", and click "Permissions...". In the dialog, click Advanced. In the new dialog, click "Add...", then input "Everyone". Finally, check the following permissions for denied as is shown:

In this way, Bitvise SSH Server itself will no longer be able to alter these values, and then I got the correct output form my Bitvise SSH sessions.

Finally, Oh My Zsh looks the same whether it passes through Bitvise SSH Server or not.