Portabilité locale UTF-8 (et ssh)

Je passe beaucoup de temps sshsur différentes machines, toutes différentes (certaines sont intégrées, certaines exécutent Linux, certaines exécutent BSD, etc.). Sur mes propres machines locales, cependant, j'utilise OS X, qui a bien sûr un espace utilisateur basé sur BSD. Mon environnement local sur ces machines est défini sur en_GB.UTF-8, qui est l'une des options disponibles:

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

Plusieurs des systèmes Linux les plus performants que j'utilise semblent avoir une option équivalente, mais je note que sous Linux, le nom est légèrement différent:

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

Cela me fait me demander: lorsque j'entre sshdans une machine Linux à partir de mon Mac et qu'il transfère toutes mes LC_*variables avec ce suffixe «UTF-8», cette machine Linux comprend-elle même ce qui lui est demandé? Ou est-ce que cela revient simplement à un autre endroit?

edit: Voici un exemple de ce à quoi je fais référence:

% 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:~ % 

Dans les deux cas, quel est le mécanisme derrière son comportement et dépend-il d'une configuration particulière (par exemple, verrai-je le même comportement sur un système basé sur BusyBox que sur un système basé sur GNU)?

C'est une question intéressante, mais je pense qu'il peut y avoir une idée fausse là-dessus sur la façon dont les variables sont configurées. Lorsqu'une session shell sécurisée est lancée ( ssh remotehost), ce qui se passe à l'autre extrémité est une instanciation d'un nouveau shell avec un environnement séparé. C'est une façon élégante de dire que le serveur démarre un nouveau shell. Ce nouveau shell peut être configuré ou non avec les mêmes paramètres régionaux que votre shell local d'origine.

Par exemple

geee: ~
$ echo `locale | grep LANG` ::` date`
LANG = en_US.UTF-8 :: 3 déc. 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

Afin de le démontrer, j'ai configuré les paramètres régionaux sur le shell distant pour le norvégien en ajoutant les lignes suivantes au fichier ~ / .bash_profile:

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

De même, vous devrez configurer l'environnement sur le shell distant pour faire de même. Bien sûr, d'autres shells lisent différents fichiers de démarrage tels que ~ / .zprofile pour le shell Z.

L'idée fausse que je soupçonnais résidait dans le fait que les variables locales (paramètres) ne sont en aucun cas transmises. Le shell distant a ses propres paramètres. Afin de répertorier les langues disponibles sur l'hôte distant, que ce soit un shell BusyBox minimaliste ou un OS GNU complet, utilisez la localecommande avec le -acommutateur (comme indiqué dans la question). N'importe laquelle des lignes imprimées peut être utilisée comme paramètre de paramètres régionaux pour cet environnement.

Comme pour la première question, les paramètres régionaux par défaut avec lesquels tout shell démarre sont généralement configurés dans un emplacement central tel que / etc / profile. La plupart des shells de connexion lisent ce fichier au démarrage.

Le nom de la prise en charge UTF-8 est-il légèrement différent sur différents systèmes pour la commande suivante également?

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

Si vous rencontrez des étranges questions relatives à la locale, il peut aider à dire au client SSH de ne pas envoyer les LC_*variables en commentant SendEnv LANG LC_*dans /etc/ssh_config(voir, par exemple, fixation Mac OS X UTF-8 SSH Lion Questions et Terminal sous Mac OS X Lion: la boîte n'écrivez pas åäö sur une machine distante ).

Une autre approche de solution est la suivante:

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