Caracteres ilegíveis de SSH no vim / nano no servidor remoto


18

... e isso está me deixando louco.

Basicamente (isso vem acontecendo nos últimos dois meses), faço logon em alguns servidores CentOS diferentes (um Linode, outro VPS e um host compartilhado ao qual tenho acesso ao shell), executando 5.5, 5.7 e 6, do meu Mac executando o OS X Lion, usando o Terminal.

Basicamente:

$ ssh username@example.com

[remote-host] $ nano somefile.txt

Depois que eu começar a editar o arquivo, se eu usar as teclas de seta para mover o cursor ou começar a excluir e digitar novamente, o cursor saltará um pouco e, se eu salvar o arquivo e reabri-lo, é óbvio que o cursor estava , de fato, pulando por toda parte em uma linha sem motivo aparente.

Acabo recebendo coisas como "Este é um texto neof." Quando eu digitei (para o editor louco pelo cursor) "Esta é uma linha de texto".

É um grande problema quando se trata de editar arquivos de configuração, porque geralmente tenho que editar uma linha, salvar e fechar e reabrir apenas para garantir que a linha esteja correta ... depois edite outra linha ... e está ficando muito chato .

Encontrei problemas de renderização do Linode Lish Shell Vim e Nano: linhas não aparecendo / posições do cursor incorretas , mas não sei se isso se relaciona muito, pois isso se refere especificamente a lish.


1
Hey @geerlingguy, eu postei uma resposta para essa pergunta anos atrás, quando seu nome não significava nada para mim, mas agora eu uso seu trabalho regularmente. Obrigado por todas as suas contribuições ansible!
dbenton

1
@dbenton - Posso ajudá-lo, você me ajudar, nós somos uma comunidade feliz :)
geerlingguy

Respostas:


14

[ Atualização: A partir do Mac OS X Mountain Lion 10.8, o Terminal suporta a sequência de escape Backtab, eliminando esse problema.]

As versões do nano nesses servidores às vezes enviam uma sequência Backtab (ESC [Z) ao mover o cursor para a esquerda por um caractere, mas o Terminal não suporta essa sequência, portanto, o nano acha que o cursor se moveu quando não possui ' te sua idéia sobre a posição atual do cursor está fora de sincronia com o terminal.

Por razões que não consigo entender, o nano envia uma Backtab ao mover para a esquerda e o cursor é um caractere à direita de uma tabulação. Da mesma forma, o IIRC envia uma guia (Control-I) ao mover para a direita e o cursor é um caractere à esquerda de uma parada de tabulação. Não sei por que isso faz com que a guia pare em vez de sempre mover para a esquerda / direita usando as mesmas seqüências de caracteres. A versão do nano fornecida com o Mac OS X Lion 10.7 não faz isso.

O Nano só faz isso quando o terminfo diz que o cbtrecurso é suportado. O terminfo padrão para o Terminal é xterm-256color, que declara esse recurso e o mapeia para a sequência Backtab. Uma solução alternativa é definir a TERMvariável de ambiente para algo que não declare esse recurso. Você pode fazer isso na máquina local antes de chamar sshou no arquivo de inicialização do shell no host remoto. A configuração é xterm-colorfácil, embora não seja recomendável, pois desativa outros comportamentos importantes (por exemplo, 256 cores, BCE, preservação de conteúdo alternativo da tela). (Uma abordagem mais pesada é personalizar seu arquivo xterm-256color(ou xterm) terminfo no host remoto para remover cbt.)

É recomendável personalizar o host remoto (de uma maneira ou de outra), para que as personalizações não se apliquem localmente ou a outros hosts remotos, mas a solução mais simples é alterar uma configuração de preferência do Terminal para usar em xterm-colorvez de xterm-256color:

Terminal> Preferências> Configurações> [perfil]> Avançado> Declarar terminal como:

Eu recomendo duplicar um perfil de configurações existente, personalizá-lo e usá-lo apenas quando você estiver se conectando a esses hosts remotos.


Definir xterm-color definitivamente funciona - você poderia elaborar como personalizar meu arquivo terminfo no host remoto? Um link faria, mas eu provavelmente será voltar a este post de vez em quando para lembrar esta dica :)
geerlingguy

1
@geerlingguy Modificando uma definição existente de terminfo . Remova a cbt=\E[Zentrada no .tiarquivo de origem.
TachyonVortex

Isso me ajudou, defini a opção de xterm-256color para xterm e agora posso selecionar, copiar, etc. como costumava fazer antes. (Não sei como ou quem mudou essa opção). Obrigado!
Spacebiker 11/08/16

8

Eu estava tendo o mesmo problema. Encontrei este segmento que recomendava, entre outras soluções, uma variável de ambiente no servidor remoto:

export TERM=xterm-color

Adicionar isso a ~ / .bash_profile resolveu o problema para mim. Esta solução é simples e tem o benefício de afetar apenas um usuário específico em um host específico.


2

Eu tive o mesmo problema no programa MobaXTerm. A causa do problema foi a tecla -K, que eu usei para ativar o numpad no Nano ao usar o PuTTY. Como descobri no MobaXTerm -K não é necessário (o numpad funciona por padrão) e sem ele as teclas de seta funcionam corretamente e não inserem lixo aleatoriamente.


1

OSX 10.7.4 com o Centos em execução como sistema operacional convidado

Nas preferências do terminal OSX, configurações, opções avançadas

Declare terminal as:xterm-color
Strict VT-100 keypad behaviour - TICKED!

Não há mais problemas :)


Observe que a preferência "comportamento do teclado VT-100" não tem nenhuma relação com essas perguntas e respostas e não tem efeito sobre o resultado.
Chris Page

1

Para usuários do MobaXterm. Se você não estiver usando -K e ainda estiver com o problema. Verifique se as seguintes linhas estão comentadas no seu arquivo / etc / nanorc.

# set rebinddelete

# set rebindkeypad


0

O provável problema é que, sim, sua máquina local e seu servidor ESTÃO em sistemas unix com nano, mas essas versões podem ser diferentes.

export TERM=xterm-color

-1

Se o que você recebe é "Este é um texto novo" e o que você digitou é "Esta é uma linha de texto" (devo presumir que seu relatório está correto), você tem uma chave "controle" esquisita, independentemente do que estiver no Mac (comando ? maçã?). Como o nano está usando as teclas control + para "pular" e você tem menos caracteres do que digitados, temos a) caracteres desaparecidos b) seqüências de controle que aparecem do nada, deduzindo que a) se torna b) é lógico.

Você também pode ter algum programa desagradável de tecla de atalho / macro / outros enfeites. Suspeito que isso pertença ao superusuário e não à falha do servidor, mas manterei a sinalização, talvez alguém tenha uma resposta realista e vinculada ao SSH.


Isso acontece quando eu uso as teclas de seta para mover-me para frente e para trás em uma linha, mais frequentemente do que quando estou simplesmente digitando. Mas parece bastante aleatório. Vou tentar a sugestão de Chris rapidamente para ver se funciona, mas obrigado por responder!
geerlingguy
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.