Portabilità locale UTF-8 (e ssh)

Trascorro molto del mio tempo sshin varie macchine, tutte diverse (alcune sono integrate, altre Linux, altre BSD, ecc.). Sulle mie macchine locali, tuttavia, utilizzo OS X, che ovviamente ha una userland basata su BSD. La mia locale su quelle macchine è impostata su en_GB.UTF-8, che è una delle opzioni disponibili:

% echo `sw_vers`
ProductName: Mac OS X ProductVersion: 10.8.2 BuildVersion: 12C60
% locale -a | grep -i 'en_gb.utf'
en_GB.UTF-8

Molti dei sistemi Linux più capaci che uso sembrano avere un'opzione equivalente, ma noto che su Linux il nome è leggermente diverso:

% lsb_release -d
Description: Debian GNU/Linux 6.0.3 (squeeze)
% locale -a | grep -i 'en_gb.utf' 
en_GB.utf8

Questo mi fa meravigliare: quando sshentro in una macchina Linux dal mio Mac e inoltra tutte le mie LC_*variabili con quel suffisso "UTF-8", quella macchina Linux capisce persino cosa gli viene chiesto? O sta semplicemente ricadendo in qualche altro locale?

modifica: ecco un esempio di ciò a cui mi riferisco:

% ssh -v odin
...
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_ALL = en_GB.UTF-8
debug1: Sending env LC_COLLATE = en_GB.UTF-8
debug1: Sending env LC_CTYPE = en_GB.UTF-8
debug1: Sending env LC_MESSAGES = en_GB.UTF-8
debug1: Sending env LC_MONETARY = en_GB.UTF-8
debug1: Sending env LC_NUMERIC = en_GB.UTF-8
debug1: Sending env LC_TIME = en_GB.UTF-8
debug1: Sending env LANG = en_GB.UTF-8
odin:~ % locale | tail -1  # locale is set to .UTF-8 without error...
LC_ALL=en_GB.UTF-8
odin:~ % locale -a | grep 'en_GB.UTF-8'  # ... even though .UTF-8 isn't an option
odin:~ %

In entrambi i casi, qual è il meccanismo alla base del suo comportamento e dipende da una particolare configurazione (ad esempio, vedrò lo stesso comportamento su un sistema basato su BusyBox come su uno basato su GNU)?

— vacche
fonte

spiegazione qui: superuser.com/questions/999133/… (risposta da grawity). Quindi da BSD a Linux non ci sono problemi. Da Linux (se definisce utf8 anziché UTF-8) a BSD, potrebbe esserci un problema.

— AB

Risposte:

È una domanda interessante, ma penso che ci possa essere un'idea sbagliata su come sono impostate le variabili. Quando viene avviata una sessione di shell sicura ( ssh remotehost), ciò che accade all'altra estremità è un'istanza di una nuova shell con un ambiente separato. Questo è un modo elegante per dire che il server avvia una nuova shell. Quella nuova shell può essere o meno configurata con le stesse impostazioni locali della shell locale originale.

Per esempio

geee: ~
$ echo `locale | grep LANG` ::` date`
LANG = en_US.UTF-8 :: Lun 3 dic 07:04:00 CET 2012

$ ssh flode
flode: ~
$ echo `locale | grep LANG` ::` date`
LANG = nb_NO.UTF-8 LANGUAGE = nb_NO.UTF-8 :: ma. 03. des. 06:59:33 +0100 2012

Per dimostrarlo, ho impostato la locale sulla shell remota per Norwegian aggiungendo le seguenti righe al file ~ / .bash_profile:

export     LANG=nb_NO.UTF-8
export LANGUAGE=nb_NO.UTF-8
export   LC_ALL=nb_NO.UTF-8

Allo stesso modo, dovrai configurare l'ambiente sulla shell remota per fare lo stesso. Naturalmente, altre shell leggono diversi file di avvio come ~ / .zprofile per la shell Z.

L'idea sbagliata che sospettavo risiedeva nel fatto che le variabili locali (impostazioni) non sono in alcun modo trasmesse. La shell remota ha le sue impostazioni. Per elencare le lingue disponibili sull'host remoto, che si tratti di una shell BusyBox minimalista o di un sistema operativo GNU completo, utilizzare il localecomando con l' -aopzione (come indicato nella domanda). Qualsiasi linea stampata può essere utilizzata come impostazione locale per quell'ambiente.

Per quanto riguarda la prima domanda, la locale predefinita con cui inizia qualsiasi shell è di solito configurata in una posizione centrale come / etc / profile. La maggior parte delle shell di login legge questo file all'avvio.

— Ярослав Рахматуллин
fonte

La roba locale viene sicuramente inoltrata. /etc/ssh_configsu ogni macchina che io abbia mai visto lo definisce LANGe LC_*viene inviato a tutti gli host per impostazione predefinita e ssh -vrivela diverse righe simili debug1: Sending env LC_ALL = en_GB.UTF-8. Naturalmente, se il profilo della shell sull'altra estremità successivamente lo sostituisce, questa è un'altra cosa - ma su alcune delle mie macchine, non è così

— kine

PS: ho aggiornato il mio post originale con forse una migliore illustrazione di ciò a cui mi riferisco

— kine,

Certo, non l'ho mai visto. Le macchine a cui ti riferisci, Debian? Forse questo spiegherà il meccanismo di inoltro ambientale di ssh. Continuo a pensare che i nomi delle impostazioni locali debbano corrispondere esattamente, perché le impostazioni locali non dovrebbero essere abbastanza intelligenti da capirlo. Il motivo per cui le stringhe sono diverse è perché la libreria C è diversa per le macchine basate su BSD e GNU / Linux. Non si conoscono. Ma forse sono troppo scettico e il programma locale ha un modo di adattarlo automaticamente.

— Ярослав Рахматуллин,

Questa è la parte di cui ero curioso: le sshcose di inoltro sono casuali, è solo il contesto per cui il mio locale è impostato così com'è. Semplicemente non so come determinare cosa stia effettivamente facendo la shell dall'altra parte - di solito non ricevo errori nel tentativo di impostare la locale (anche se a volte lo faccio su dispositivi incorporati) e l'immissione / visualizzazione del testo Unicode sembra funziona normalmente (?), ma il locale che sto usando non è ovviamente presente sul sistema. La maggior parte dei dispositivi Linux a cui mi collego sono basati su Debian o Ubuntu, mentre altri sono basati su uClibc / BusyBox (dispositivi di rete, ecc.).

— kine,

Il nome per il supporto UTF-8 è leggermente diverso su sistemi diversi anche per il seguente comando?

LC_ALL='' locale charmap  # UTF-8 (on Mac OS X 10.6.8)

Se riscontri strani problemi relativi alle impostazioni locali, può essere utile dire al client SSH di non inviare tali LC_*variabili commentando SendEnv LANG LC_*in /etc/ssh_config(vedi, ad esempio, Risoluzione dei problemi SSH UTF-8 di Mac OS X Lion e Terminale in OS X Lion: can scrivere åäö sulla macchina remota ).

Un altro approccio di soluzione è questo:

# from: http://mod16.org/hurfdurf/?p=189
tjac wrote:
Actually the real problem that's causing this is that Mac OS 10.7 sets totally 
non-standard locale values, at least when you tweak some of the formats in
SysPrefs/Language&Text as I did.

If you type "locale" on your Mac terminal you should see pretty much the same as on 
other Unices (e.g. lots of en_US.UTF-8s if you prefer US English), but you don't. 
If these garbled settings get transferred to other Unix hosts by the SendEnv option 
they naturally do not know what's going on.

So if you want to fix it cleanly to allow for sshing to all kinds of remote hosts,
including those with older character sets, put the following lines in your 
~/.bash_profile on your Mac client machine.

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Monday, September 12, 2011 at 22:54 #

— karly
fonte