terminal: affichage de caractères spéciaux

Dans certains programmes, tels que htoples lignes et les cadres ne s'affichent pas correctement. Au lieu de cela, ils sont affichés comme -et /.

Mais sur une autre machine, ils s'affichent correctement sous forme de lignes appropriées:

Je ne sais pas s'il s'agit d'un problème de terminal, ou si un package est peut-être nécessaire.

Dans le cas où cela est pertinent: mon système est Debian Wheezy, mon interprète est bashet mon émulateur de terminal estgnome-terminal

Votre exemple principal s'exécute avec un environnement local non Unicode (c'est-à-dire ASCII). Vérifiez votre variable d'environnement $ LANG (essayez export | grep LANG); vous ne trouverez probablement pas de .UTF-8suffixe. Essayez de l'ajouter:

export LANG=$LANG.UTF-8

Votre autre exemple s'exécute avec une locale UTF-8, qui devrait être la valeur par défaut pour les shells récents. Il semble htopdétecter vos paramètres régionaux et afficher des caractères ASCII ou Unicode - donc dans l'image du bas, vous obtenez de beaux caractères Unicode, tandis qu'avec ASCII, vous obtenez quelques jolis caractères de fortune. Je suggère de changer les paramètres régionaux de la machine de l'image du haut en un Unicode (voir Paramètres régionaux - Wiki Debian ).

Si cela ne fonctionne pas, il se peut que votre émulateur de terminal soit le problème. L'encodage par défaut peut être non Unicode. Changez l'encodage par défaut de votre émulateur de terminal en UTF-8 ( xfce4-terminalje l'ai trouvé dans l'onglet Avancé). Si vous ne le pouvez pas, il se peut que votre police actuelle ne prenne pas en charge Unicode: essayez de changer votre police en Unicode.

[Étrangement, j'ai trouvé une fois que j'avais changé mes paramètres régionaux en ASCII une fois dans une session shell, htopaffiche toujours les caractères ASCII, même après l'avoir changé. Cela pourrait être votre problème si, pour une raison quelconque, vous modifiez occasionnellement votre locale dans votre shell.]

La chose étrange est qu'elle htoputilise ncurses, qui peut tracer des lignes avec / sans Unicode. Cependant, regarder le code source dans CRT.cmontre l'explication:

#ifdef HAVE_LIBNCURSESW
   if(strcmp(nl_langinfo(CODESET), "UTF-8") == 0)
      CRT_utf8 = true;
   else
      CRT_utf8 = false;
#endif

   CRT_treeStr =
#ifdef HAVE_LIBNCURSESW
      CRT_utf8 ? CRT_treeStrUtf8 :
#endif
      CRT_treeStrAscii;

et la CRT_treeStrUtf8valeur est

const char *CRT_treeStrUtf8[TREE_STR_COUNT] = {
   "\xe2\x94\x80", // TREE_STR_HORZ ─
   "\xe2\x94\x82", // TREE_STR_VERT │
   "\xe2\x94\x9c", // TREE_STR_RTEE ├
   "\xe2\x94\x94", // TREE_STR_BEND └
   "\xe2\x94\x8c", // TREE_STR_TEND ┌
   "+",            // TREE_STR_OPEN +
   "\xe2\x94\x80", // TREE_STR_SHUT ─
};

Cependant, ncurses (toute implémentation de curses) a des symboles portables pour ceux-ci qui ne dépendent pas du fait que le codage soit UTF-8 ou non. Certaines applications (comme l' option de dialogue--ascii-lines ) offrent une option pour utiliser le dessin au trait ASCII, mais une application qui n'essaie même pas d'utiliser le dessin au trait fourni dans ncurses n'utilise pas efficacement la bibliothèque.

En bref, lorsque vous rencontrez un programme qui se comporte comme ça, vous devez le signaler comme un bug aux développeurs.

Lectures complémentaires:

• Graphiques linéaires (page de manuel ncurses addch)
• border, wborder, box, hline, whline, vline, wvline, mvhline, mvwhline, mvvline, mvwvline- créer des bordures curses, des lignes horizontales et verticales
• dialogcaptures d'écran ( aucune ne nécessite un encodage UTF-8 pour utiliser le dessin au trait)