Rileva la quantità di Unicode supportata dal mio terminale, anche attraverso lo schermo

Ecco il problema: voglio essere in grado di discernere se il mio terminale è in grado di unicode decente o meno, al fine di utilizzare alcuni caratteri o meno, proprio come gli sguardi, che a volte usa colori e altri sottolineati.

La motivazione sorge perché in qualsiasi tipo di terminale virtuale ottengo caratteri decenti, ma capisco che la console di base Linux ha un set di caratteri di 256 o 512 simboli simultanei, quindi non puoi aspettarti il ​​pieno supporto dei caratteri.

All'inizio ho pensato che avrei potuto usare $TERMo tty, ma ecco il trucco: sto usando anche byobu, quindi $TERMè sempre "screen.linux". Anche l'output di tty non è molto significativo: /dev/pts/<some number>in termini sia "reali" che virtuali.

$BYOBU_TTYnon è nemmeno di aiuto, perché ad esempio potrebbe essere /dev/tty1e quando la sessione è aperta in Ctrl+ Alt+ F1i personaggi non vengono visualizzati ma quando si attaccano alla stessa sessione da un termine X, vengono visualizzati correttamente e comunque $BYOBU_TTYnon cambiano. Inoltre, vorrei essere in grado di rilevare questo senza presumere che byobu ci sia o no.

Inoltre, la localizzazione mostra in tutti i casi en_US.UTF-8

Tuttavia, in qualche modo gli sguardi (per nominare uno strumento particolare che vedo rilevare questo), anche all'interno di Byobu, utilizza un output diverso a seconda del terminale che sto collegando alla sessione di Byobu.

Sto riscontrando problemi con google perché terminal e tty sembrano termini di ricerca troppo comuni. Al massimo arrivo a soluzioni consigliate $TERMo tty.

Bene, per prima cosa suppongo che vorrei sottolineare che praticamente tutti i terminali in questi giorni sono "virtuali" nel senso di cui parli ... anche se il terminale si trova all'altra estremità di una porta seriale in buona fede. Voglio dire, i giorni di VT-100 s, terminali Wyse e altri terminali "fisici", "reali" sono praticamente passati!

A parte questo, diciamo che vuoi rilevare che tipo di supporto Unicode ha il tuo terminale. Puoi farlo scrivendo i personaggi di prova su is e vedendo cosa succede. (Puoi fare uno sforzo per cancellare i caratteri di prova dopo averlo scritto, ma l'utente potrebbe ancora vederli brevemente, o cancellarli potrebbe non funzionare correttamente in primo luogo.)

L'idea è di chiedere al terminale di dirti la sua posizione del cursore, emettere un carattere di prova, chiedere nuovamente al terminale di dirti la sua posizione e confrontare le due posizioni per vedere quanto si è spostato il cursore del terminale.

Per chiedere la posizione al terminale, vedere qui . Essenzialmente:

echo -e "\033[6n"; read -d R foo; echo -en "\nCurrent position: "; echo $foo | cut -d \[ -f 2

Prova a produrre "é". Questo personaggio richiede 2 byte in UTF-8 ma viene visualizzato in una sola colonna sullo schermo. Se si rileva che l'output di "é" provoca lo spostamento del cursore di 2 posizioni, il terminale non ha alcun supporto UTF-8 e probabilmente ha generato un qualche tipo di immondizia. Se il cursore non si muoveva affatto, allora il terminale è probabilmente solo ASCII. Se si sposta di 1 posizione, quindi congratulazioni, probabilmente può visualizzare parole francesi.

Prova a produrre "あ". Questo personaggio richiede 3 byte in UTF-8 ma viene visualizzato solo in due colonne sullo schermo. Se il cursore si sposta di 0 o 3, cattive notizie, simili a quelle sopra. Se si sposta di 1, sembra che il terminale supporti UTF-8 ma non sia a conoscenza di caratteri ampi (in caratteri a larghezza fissa). Se si sposta di 2 colonne, va tutto bene.

Sono sicuro che ci sono altri caratteri sonda che potresti emettere che porterebbero a informazioni utili. Non sono a conoscenza di uno strumento che lo fa automaticamente.

La vera domanda di OP è: quali valori Unicode supporta la console Linux e quali possono essere rilevati durante l'esecuzione screen. In linea di principio, è possibile farlo recuperando la mappa Unicode per la console.

L' kbdalbero dei sorgenti contiene getunimap(e la sua pagina di manuale). La pagina del manuale dice questo

Il programma getunimap è vecchio e obsoleto. Ora fa parte di setfont

che non è esattamente vero. setfontha un'opzione che fa all'incirca la stessa cosa:

   -ou file                                  
          Save previous Unicode map in file

Le differenze:

• setfontscrive su un file, mentre getunimapscrive sullo standard output
• getunimap mostra il personaggio che verrebbe mappato, come commento.

Per esempio:

0x0c4   U+2500  # ─ 
0x0c4   U+2501  # ━ 
0x0b3   U+2502  # │ 
0x0b3   U+2503  # ┃ 
0x0da   U+250c  # ┌ 
0x0da   U+250d  # ┍ 
0x0da   U+250e  # ┎ 
0x0da   U+250f  # ┏ 
0x0bf   U+2510  # ┐ 
0x0bf   U+2511  # ┑ 
0x0bf   U+2512  # ┒ 
0x0bf   U+2513  # ┓ 
0x0c0   U+2514  # └ 
0x0c0   U+2515  # ┕ 
0x0c0   U+2516  # ┖ 
0x0c0   U+2517  # ┗ 

contro

0xc4    U+2500
0xc4    U+2501
0xb3    U+2502
0xb3    U+2503
0xda    U+250c
0xda    U+250d
0xda    U+250e
0xda    U+250f
0xbf    U+2510
0xbf    U+2511
0xbf    U+2512
0xbf    U+2513
0xc0    U+2514
0xc0    U+2515
0xc0    U+2516
0xc0    U+2517

Se si esegue screen(o ad esempio in esecuzione xterme non sulla console), verrà visualizzato un errore di autorizzazione che è possibile aggirare utilizzando sudo.

Se mi capita di sapere quale carattere è stato caricato, posso verificare che (senza autorizzazioni speciali) utilizzando psfgettable, ad esempio,

zcat /usr/share/consolefonts/Lat2-Fixed16.psf.gz | psfgettable -

e vedere i dati di mappatura che setfontutilizzerebbero per caricare il carattere (con la mappatura Unicode):

#
# Character table extracted from font -
#
0x000   U+00a9
0x001   U+00ae
0x002   U+00dd
0x003   U+0104
0x004   U+2666 U+25c8 U+fffd
0x005   U+0105
0x006   U+0111
0x007   U+0150
0x008   U+0151
0x009   U+0162
0x00a   U+0164
0x00b   U+0170
0x00c   U+0171
0x00d   U+021a 
0x00e   U+02dd  
0x00f   U+2014 U+2015
0x010   U+2020
0x011   U+2021
0x012   U+2022 U+25cf
...

Entrambi getunimape setfontforniscono i dati non ordinati, mentre psfgettablesembrano essere ordinati (oltre a combinare le linee per i valori Unicode associati allo stesso glifo). Quindi ci sono differenze, ma le informazioni sono accessibili.

Ulteriori letture (che illustrano perché non è possibile utilizzare showconsolefontper risolvere questo problema):

• Perché showconsolefont ha un output diverso in tmux?
• Stampa i dati binari così come sono senza rompere il terminale

Mi sono imbattuto in questa domanda mentre cercavo di realizzare la stessa cosa, ma non volevo lasciare nulla sullo schermo e impostarlo come variabile, quindi ho inserito quanto segue in uno script shell che ho sorgente:

function test_unicode {
  echo -ne "\xe2\x88\xb4\033[6n\033[1K\r"
  read -d R foo
  echo -ne "\033[1K\r"
  echo -e "${foo}" | cut -d \[ -f 2 | cut -d";" -f 2 | (
    read UNICODE
    [ $UNICODE -eq 2 ] && return 0
    [ $UNICODE -ne 2 ] && return 1
  )
}

test_unicode
RC=$?
export UNICODE_SUPPORT=`[ $RC -eq 0 ] && echo "Y" || echo "N"`
unset test_unicode