terminale: mostra caratteri speciali

In alcuni programmi, come htoplinee e frame, non vengono visualizzati correttamente. Invece, vengono visualizzati come -e /.

Ma su un'altra macchina, vengono visualizzati correttamente come linee appropriate:

Non sono sicuro che si tratti di un problema terminale o se forse è necessario un pacchetto.

Nel caso sia rilevante: il mio sistema è Debian Wheezy, il mio interprete è bashe il mio emulatore di terminale lo ègnome-terminal

L'esempio principale è in esecuzione con impostazioni internazionali non Unicode (ovvero ASCII). Controlla la tua variabile d'ambiente $ LANG (prova export | grep LANG); molto probabilmente non troverai un .UTF-8suffisso. Prova ad aggiungerlo:

export LANG=$LANG.UTF-8

L'altro esempio è in esecuzione con un'impostazione internazionale UTF-8, che dovrebbe essere l'impostazione predefinita per le shell recenti. Sembra che htoprilevi le tue impostazioni locali e visualizzi caratteri ASCII o Unicode - quindi nell'immagine in basso, ottieni simpatici personaggi Unicode, mentre con ASCII ne ottieni alcuni piuttosto improvvisati. Suggerirei di cambiare le impostazioni locali della macchina dell'immagine in alto in una Unicode (vedi Impostazioni locali - Debian Wiki ).

Se il problema persiste , è possibile che l' emulatore di terminale sia il problema. La codifica predefinita potrebbe essere non Unicode. Cambia la codifica predefinita del tuo emulatore di terminale in UTF-8 (in xfce4-terminalHo trovato nella scheda Avanzate). Se non ci riesci, è possibile che il tuo carattere attuale non supporti Unicode: prova a cambiarlo con uno Unicode.

[Stranamente, ho scoperto che una volta avevo cambiato la mia locale in ASCII una volta in una sessione di shell, htopvisualizza sempre i caratteri ASCII, anche dopo averlo cambiato di nuovo. Questo potrebbe essere il tuo problema, se per qualche motivo stai cambiando le impostazioni internazionali nella tua shell di tanto in tanto.]

La cosa strana è che htopusa ncurses, che può disegnare linee con / senza Unicode. Tuttavia, guardando il codice sorgente in CRT.cmostra la spiegazione:

#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;

e il CRT_treeStrUtf8valore è

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 ─
};

Tuttavia, ncurses (qualsiasi implementazione di curses) ha simboli portatili per questi che non dipendono dal fatto che la codifica sia UTF-8 o meno. Alcune applicazioni (come dialogo 's --ascii-linesopzionale) forniscono un'opzione per l'utilizzo di ASCII line-disegno, ma un'applicazione che non ha nemmeno tentare di utilizzare la linea-disegno fornito in ncurses non è fare un uso efficace della biblioteca.

In breve, quando ti imbatti in un programma che si comporta in questo modo, dovresti segnalarlo come un bug agli sviluppatori.

Ulteriori letture:

• Line Graphics (pagina di manuale di addc ncurses)
• border, wborder, box, hline, whline, vline, wvline, mvhline, mvwhline, mvvline, mvwvline- creare maledizioni confini, linee orizzontali e verticali
• dialogschermate ( nessuna richiede la codifica UTF-8 per utilizzare il disegno)