Servidor SSH Bitvise colocando espaços extras na sessão

Question

Estou usando o Bitvise SSH Server na minha máquina Windows para acesso remoto. O shell de login é ZSH, e eu estou usando o Oh My Zsh com ele. No entanto, eu também tentei BASH e tenho o mesmo problema. Portanto, eu acho que esse problema é com o Bitvise SSH Server, não com os shells do Cygwin ou com os emuladores de terminal do lado do cliente.

O problema pode ser percebido no prompt do meu ZSH. Enquanto a minha sessão SSH passar pelo Servidor SSH Bitvise, haverá alguns espaços extras no prompt. Por favor, veja as imagens:

EstewindowséoMinTTYnessamáquinaWindows.Quandoabro,vocêpodeverqueháapenasumespaçofinalapós~(antesdedigitarssh127.0.0.1).Noentanto,umavezqueeuSSH-ednamesmamáquina,existemdoisespaçosàdireitaapós~noprompt.Alémdisso,seeufizeroutrasessãoSSH(paraamáquinatiger)dentrodasessãoBitviseSSH,opromptdosegundotambémteráespaçosextras(promptssublinhadosemvermelho).Noentanto,seeusairdasessãodoBitviseedoSSHparatiger,diretamente,opromptseránormal(promptssublinhadosemverde).

Euobserveiomesmoaoconectardealgumamáquinaremota(usandognome-terminalouxfce4-terminalcomoemuladordeterminal)aessamáquinaWindows.

Portanto,minhaconclusãoéqueoemuladordeterminalnãoéoculpadoporisso.OCygwineseuZSHtambémnãotêmculpa,porquetudoparecebem,desdequeeunãopassepeloBitvise.

MinhasuposiçãoédequeháalgumcaractereespecialdefinidonotemaOhMyZshquenãoéprocessadocorretamenteaopassarpeloBitvise.Noentanto,nãoconseguidescobriroqueéissoexatamente.OstemasdoOhMyZshficambemnolocal,semumaconexãoSSHBitvise,eficambememtodasasmáquinasLinuxquetenho.Portanto,achoquedeveriaseralgocomoBitvise.

Comosugeridonoscomentários,executeisetemambososambienteseobtiveassaídasdespejadasemdoisarquivosdetexto:bitvise.txtelocal.txt.Agora,omaiorproblemaéquenãopossocompará-losusandodiffporquediffafirmaqueelessãoarquivosbinários(eelessãodiferentes).Nãotenhocertezaseissotemalgoavercomosespaçosestranhos.

ForçarLANGondiffnãoajudou.

$diff-uNbitvise.txtlocal.txtBinaryfilesbitvise.txtandlocal.txtdiffer$LANG=en_US.UTF-8diff-uNbitvise.txtlocal.txtBinaryfilesbitvise.txtandlocal.txtdiffer$LANG=Cdiff-uNbitvise.txtlocal.txtBinaryfilesbitvise.txtandlocal.txtdiffer

Osdoisarquivossãoenviadosaqui: link

Testou algumas configurações diferentes de TERM ... Não pareceu fazer nada de bom. A configuração TERM=linux resultou da mesma forma com xterm .

Atualizadoem23/5/16

Oproblemaparecesermaisdifícildoqueeuesperava.Euencontreiumapasta"C: \ Arquivos de Programas \ Bitvise SSH Server \ TermInfo", que contém os arquivos de informação do terminal. Eu substituí os arquivos naquela pasta por arquivos semelhantes que copiei de uma máquina normal do Ubuntu, mas não ajudei. Eu também tentei a informação do termo "cygwin" que é instalada com o Cygwin, sem sorte ... Na verdade, o arquivo "cygwin" que vem com o Cygwin é o mesmo com o que vem com o Ubuntu ...

Eu não tenho ideia agora.

Quando faço SSH no servidor SSH Bitvise, posso fazer exec /bin/bash para substituir a sessão atual pelo Bash. No entanto, nesse Bash, se eu SSH em alguma outra máquina Linux que usa Zsh e Oh My Zsh, o mesmo problema persiste.

    

Answer 1

Uma possibilidade é que o Oh My Zsh renderize caracteres Unicode e que o problema é que esses caracteres têm larguras diferentes em um console do Windows.

Por exemplo, um caractere com largura 0 no MinTTY pode ter largura 1 no console do Windows e avançaria o cursor. Ou um caractere com largura 1 no MinTTY pode ter largura 2 no console do Windows.

Nas imagens que você forneceu, você está olhando para o zsh com "Oh My Zsh" em MinTTY.

Mas e em um console do Windows? Como o Oh My Zsh está lá?

O Bitvise SSH Server executa o seu terminal shell em um console oculto do Windows, o que é necessário para poder executar programas de console do Windows. Devido a esta arquitetura, o zsh tem que parecer certo em um console do Windows para renderizar corretamente via Bitvise SSH Server.

    

Answer 2

Quatro semanas depois, finalmente descobri o problema. Obrigado ao denis bider que parece vir da equipe de suporte do Bitvise SSH Server. Sua explicação sobre como o Bitvise executa shells no console do Windows é a chave para resolver esse problema.

Descobriu-se que a variável de ambiente $TREM e os arquivos terminfo são irrelevantes.

O problema que realmente tive foi, os temas do Oh My Zsh que estou usando têm caracteres que são exibidos de outras maneiras no meu console do Windows. No entanto, descobri que, na verdade, a página de códigos do meu console do Windows está definida como 936 (chinês simplificado) devido às configurações locais do Windows (para caracteres não-Unicode). Descobri que, se eu alterar manualmente minha página de código para 437 (inglês dos EUA) na sessão SSH Bitvise, a saída se torna correta.

Então, percebi que, para os usuários dos EUA, eles nem sequer têm esse problema!

Portanto, a solução é definir a página de código padrão do console do Windows SSH Bitvise para 437. Isso pode ser feito no Registro, mais especificamente, na chave HKCU\Console\Bitvise toterms.exe , há um CodePage para ser definido como 437 (decimal). Também removi FaceName porque não parece necessário.

Noentanto,definirissosozinhonãoésuficiente,porqueacheitodavezqueumasessãoSSHBitviseéiniciada,ovalorédefinidodevoltapara936.Portanto,precisoalteraraspermissõesdeHKCU\Console\Bitvisetoterms.exeparanegaracessodegravaçãodeTodos.Passos:1.Cliquecomobotãodireitodomouseem"Bitvise toterms.exe" e clique em "Permissões ...". Na caixa de diálogo, clique em Avançado. Na nova caixa de diálogo, clique em "Adicionar ..." e digite "Todos". Por fim, verifique as seguintes permissões para negadas, conforme mostrado:

Destaforma,opróprioservidorSSHBitvisenãopoderámaisalteraressesvalores,eentãoeuobtiveoformuláriodesaídacorretoemminhassessõesBitviseSSH.

Finalmente,OhMyZshpareceomesmo,querpassepeloBitviseSSHServerounão.