Personnages de brouillage SSH dans vim / nano sur un serveur distant

... et ça me rend fou.

Fondamentalement (cela s'est produit au cours des derniers mois), je me connecte à quelques serveurs CentOS différents (un Linode, un autre VPS et un hôte partagé auquel j'ai accès au shell), exécutant 5.5, 5.7 et 6, à partir de mon Mac exécutant OS X Lion, à l'aide de Terminal.

Fondamentalement:

$ ssh username@example.com

[remote-host] $ nano somefile.txt

Une fois que j'ai commencé à éditer le fichier, si j'utilise les touches fléchées pour se déplacer dans le curseur, ou commencer à supprimer, puis à taper à nouveau, le curseur saute un peu, et si j'enregistre le fichier et le rouvre, il est évident que le curseur était , en fait, sauter partout sur une ligne sans raison apparente.

Je finis par obtenir des choses comme "Ceci est un texte néof". Quand j'avais tapé (à l'éditeur fou de curseur) "Ceci est une ligne de texte."

C'est un gros problème quand il s'agit de modifier des fichiers de configuration, car je dois souvent modifier une ligne, enregistrer et fermer, puis rouvrir juste pour m'assurer que la ligne est correcte ... puis modifier une autre ligne ... et ça devient assez ennuyeux .

J'ai trouvé des problèmes de rendu Linode Lish Shell Vim et Nano: les lignes n'apparaissent pas / les positions du curseur sont incorrectes , mais je ne sais pas si cela se rapporte beaucoup, car cela fait spécifiquement référence à lish.

[ Mise à jour: à partir de Mac OS X Mountain Lion 10.8, Terminal prend en charge la séquence d'échappement Backtab, éliminant ce problème.]

La version (s?) De nano sur ces serveurs envoie parfois une séquence Backtab (ESC [Z) lorsque vous déplacez le curseur vers la gauche d'un caractère, mais Terminal ne prend pas en charge cette séquence, donc nano pense que le curseur s'est déplacé lorsqu'il n'a pas '' t et son idée de la position actuelle du curseur n'est pas synchronisée avec le terminal.

Pour des raisons que je ne peux pas comprendre, nano envoie un Backtab lors du déplacement vers la gauche et le curseur est un caractère à droite d'un taquet de tabulation. De même, IIRC, il envoie un Tab (Control-I) lors du déplacement vers la droite et le curseur est un caractère à gauche d'un taquet de tabulation. Je ne sais pas pourquoi il fait cela autour des taquets au lieu de toujours se déplacer vers la gauche / droite en utilisant les mêmes séquences de caractères. La version de nano livrée avec Mac OS X Lion 10.7 ne fait pas cela.

Nano ne le fait que lorsque le terminfo indique que la cbtcapacité est prise en charge. Le terminfo par défaut pour Terminal est xterm-256color, qui déclare cette capacité et la mappe à la séquence Backtab. Une solution de contournement consiste à définir la TERMvariable d'environnement sur quelque chose qui ne déclare pas cette capacité. Vous pouvez le faire sur la machine locale avant d'appeler sshou dans le fichier de démarrage du shell sur l'hôte distant. Le paramétrer sur xterm-colorfera l'affaire, bien qu'il ne soit pas recommandé, car il désactive d'autres comportements importants (par exemple 256 couleurs, BCE, préservation du contenu de l'écran alternatif). (Une approche plus lourde consiste à personnaliser votre xterm-256color(ou xterm) fichier terminfo sur l'hôte distant à supprimer cbt.)

La personnalisation de l'hôte distant (d'une manière ou d'une autre) est recommandée, afin que les personnalisations ne s'appliquent pas localement ou à d'autres hôtes distants, mais la solution la plus simple consiste à modifier un paramètre de préférence de terminal à utiliser xterm-colorau lieu de xterm-256color:

Terminal> Préférences> Paramètres> [profil]> Avancé> Déclarez le terminal comme:

Je recommande de dupliquer un profil de paramètres existant, de le personnaliser et de ne l'utiliser que lorsque vous vous connectez à ces hôtes distants.

J'avais ce même problème. J'ai trouvé ce fil qui recommandait, entre autres solutions, une variable d'environnement sur le serveur distant:

export TERM=xterm-color

L'ajout de ceci à ~ / .bash_profile a résolu le problème pour moi. Cette solution est simple et a l'avantage de n'affecter qu'un utilisateur spécifique sur un hôte spécifique.

J'ai eu le même problème dans le programme MobaXTerm. La cause du problème était la touche -K que j'ai utilisée pour activer le pavé numérique dans Nano lors de l'utilisation de PuTTY. Comme je l'ai découvert dans MobaXTerm -K n'est pas nécessaire (le pavé numérique fonctionne par défaut) et sans lui, les touches fléchées fonctionnent correctement et n'insèrent pas les ordures au hasard.

OSX 10.7.4 avec Centos exécuté en tant qu'OS invité

Dans les préférences du terminal OSX, les paramètres, avancés

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

Plus de problèmes :)

Pour les utilisateurs de MobaXterm. Si vous n'utilisez pas -K et rencontrez toujours le problème. Assurez-vous que les lignes suivantes sont mises en commentaire dans votre fichier / etc / nanorc.

# set rebinddelete

# set rebindkeypad

Le problème probable est que, oui, votre machine locale et votre serveur SONT sur des systèmes Unix qui ont nano, mais ces versions nano peuvent être différentes.

export TERM=xterm-color

Si ce que vous obtenez est "Ceci est un texte neof" et ce que vous avez tapé est "Ceci est une ligne de texte" (je dois présumer que votre rapport est correct) alors vous avez une touche "contrôle" feuilletée quoi que ce soit sur Mac (commande ? Pomme?). Parce que nano utilise les touches Ctrl + pour "sauter" et que vous avez moins de caractères que tapés, nous avons a) des caractères disparus b) des séquences de contrôle apparaissant à partir de rien, déduisant que a) devient b) est logique.

Vous pouvez également avoir un programme de touches de raccourci / macro / autres. Je soupçonne que cela appartient au superutilisateur et non au défaut de serveur, mais je tiendrai le signalement, peut-être que quelqu'un a une réponse réaliste liée à SSH.