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:

Differences between a session that goes through Bitvise and one that doens't

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

Different TERM settings

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.

  • use set to dump the full settings in the several cases. May be you can find a discrepancy – matzeri May 5 '16 at 6:05
  • @matzeri Finally got time to do this... I did set > local.txt locally and did set > bitvise.txt in an SSH session to localhost. Now I got the two files, both very big and not exactly the same. However diff claims they are binary files so not outputting differences in lines... Still trying to figure out a way for this... – bfrguci May 7 '16 at 0:01
  • different locale ? see man iconv for conversion – matzeri May 7 '16 at 16:19
  • @matzeri They don't seem to be different locales because they are both UTF-8 when I open them with Sublime Text... Are they just too big for diff (or too many differences)? – bfrguci May 10 '16 at 1:37
  • diff can handle huge files and all file different. If it complains about binary or your locale is not UTF8 or one of the caracther is not a valid UTF8. You can also try LANG=C diff -uN file1 file2 or LANG=en_US.UTF-8 diff -uN file1 file2 – matzeri May 10 '16 at 5:38

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.

  • You may be right... Oh My Zsh does not look correct in the Windows console - but it also looks different with what I see in Bitvise session. – bfrguci May 25 '16 at 17:40
  • If the problem is with Windows console, is there any possible fix for it? – bfrguci May 25 '16 at 17:40
  • If Oh My Zsh does not look correct in the Windows console, this issue would likely have to be fixed by the maintainer of the Oh My Zsh project - assuming that they want to fix this. It may also be possible that the Oh My Zsh configuration can be changed to work around the issue, but I do not have experience to say if this is possible or not. – denis bider May 27 '16 at 16:43
  • Is it possible you don't use Windows terminal but MinTTY or something else? – bfrguci May 28 '16 at 0:04
  • 1
    It would be theoretically possible but not a good architectural choice for a Windows SSH server that needs to provide access to Windows console mode programs, not least PowerShell. MinTTY does not work well with PowerShell, or with any type of advanced Windows console-mode program in general. – denis bider May 30 '16 at 2:33

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.

enter image description here

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:

enter image description here

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.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.