Les bordures Tmux s'affichent comme x q au lieu de lignes?
J'ai du mal à faire en sorte que tmux affiche des lignes pour les bordures. Ils sont créés avec x et q. C'est un serveur Debian Squeeze et les paramètres régionaux sont définis sur en_US UTF8. J'ai aussi essayé d'ajouter
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
lignes vers .tmux.conf. Rien ne semble fonctionner. Je ne sais pas si c'est un problème de localisation ou non. Il s'affiche correctement sur d'autres serveurs, mais pas sur Debian. J'apprécie tous les conseils que vous pourriez offrir! Merci...
Il existe un certain décalage entre votre émulateur de terminal et l'entrée de base de données terminfo utilisée par tmux (celui nommé par la variable d'environnement TERM lorsque vous démarrez/attachez à un serveur tmux ).
Selon le Guide de l'utilisateur VT100, Tableau 3-9: Caractères graphiques spéciaux , lorsque le "jeu de graphiques spécial" est sélectionné, x est utilisé pour dessiner la "barre verticale" et q est utilisé pour tracer "Ligne horizontale - Scan 5".
Sous terminfo , les caractères graphiques spéciaux du VT100 sont disponibles dans le cadre de la fonctionnalité Jeu de caractères alternatif; voir la section "Line Graphics" de la page de manuel terminfo (5) .
Probablement (sur votre serveur Debian) l'entrée de base de données effective terminfo indique que ACS est disponible, mais votre émulateur de terminal ne répond pas réellement aux séquences de contrôle spécifiées.
Le fichier tmux CHANGE indique que certains émulateurs de terminal (par exemple PuTTY) ne le font pas. respecter les séquences de contrôle ACS lorsqu'elles sont en mode UTF-8. Ainsi, tmux 1.4 a un changement qui le fait toujours utiliser des caractères UTF-8 au lieu des séquences ACS lorsque le client attaché spécifie qu'il peut gérer UTF-8 (c.-à-d. lors de l'attachement, -u a été donné ou UTF-8 est présent dans LC_ALL, LC_CTYPE ou LANG; l'option de fenêtre utf8 concerne ce que tmux devrait attendre des programmes qu'il exécute, pas ce qu'il peut envoyer au client attaché).
Debian "squeeze" inclut uniquement tmux 1. , donc votre tmux n'a probablement pas la fonction "préfère le dessin au trait UTF-8" (sauf si elle tire d'une source backports ).
Si vous ne pouvez pas réparer votre émulateur de terminal ni mettre à niveau au moins tmux 1.4, alors vous pourrez peut-être utiliser L'option terminal-overrides de tmux pour désactiver les capacités liées à ACS afin que tmux retombe à ASCII dessin au trait. Dans votre .tmux.conf (sur le système Debian):
set-option -ga terminal-overrides ',*:enacs@:smacs@:rmacs@:acsc@'
J'ai eu le même problème avec PuTTY et Windows 8 lors de la connexion à tmux fonctionnant sur une machine Debian Squeeze. Même lorsque j'ai défini le jeu de caractères sur UTF-8 dans PuTTY (dans les paramètres sous Fenêtre> Traduction> Jeu de caractères distant), je n'ai pas obtenu le dessin au trait correct.
Régler le Jeu de caractères distant sur "tiliser l'encodage des polices" a fait l'affaire pour moi.
Essayez de définir le jeu de caractères sur "UTF-8" et "Utiliser les points de code de dessin au trait Unicode" sous Fenêtre -> Traduction dans vos paramètres PuTTY.
J'ai eu le même problème avec PuTTY lors du lancement de tmux sur une machine Linux 12.04. Même la définition du jeu de caractères sur UTF-8 dans PuTTY (dans les paramètres sous Fenêtre> Traduction> Jeu de caractères distant) n'a pas résolu le problème.
Le lancement de tmux avec l'option -u a fait l'affaire (tmux -u)
J'ai parcouru toute la gamme de suggestions, notamment:
- confirmation des paramètres régionaux et UTF-8 dans PuTTY
- exportation NCURSES_NO_UT8_ACS = 1
- essayer manuellement différentes polices et sélections de traduction PuTTY
Ci-dessus n'a pas fonctionné. Les affichages des boîtes de dialogue indiquaient qqqq ... et xxxx avec divers caractères de coin.
Changer tous les appels de dialogue pour inclure --ascii-lines était une option mais cela impliquerait beaucoup de changements de script.
La meilleure recommandation était de changer le jeu de caractères distant pour utiliser l'encodage des polices.
PuTTY Modifier les paramètres -> Fenêtre -> Traduction -> Jeu de caractères à distance -> Utiliser l'encodage des polices
A gauche tous les autres paramètres PuTTY par défaut.
J'ai changé le paramètre de PuTTY pour le terminal en Latin-1 et cela a semblé résoudre le problème.
Si vous utilisez KiTTY il y a une case à cocher sous Windows -> onglet Traduction, qui est appelée "Autoriser le dessin au trait ACS en UTF". Il faut le vérifier:
sous Windows/PuTTY, la police que vous utilisez doit avoir les caractères pour qu'elle affiche la traduction de l'ensemble "UTF-8" et "Utiliser les points de code de dessin au trait Unicode" et la police pour "Courier-new" et la plupart de ces problèmes disparaissent
Pour moi, le problème était que j'avais oublié de faire un locale.conf fichier lorsque j'ai configuré cette boîte Arch Linux. La ligne ci-dessous a résolu le problème, remplacez votre propre langue. Un redémarrage n'était pas nécessaire pour moi.
echo "LANG=en_US.UTF-8" > /etc/locale.conf