Portabilidad local UTF-8 (y ssh)

Paso gran parte de mi tiempo ssheditado en varias máquinas, todas las cuales son diferentes (algunas están integradas, algunas ejecutan Linux, algunas ejecutan BSD, etc.). Sin embargo, en mis propias máquinas locales, uso OS X, que por supuesto tiene un país de usuario basado en BSD. Mi configuración regional en esas máquinas está establecida en en_GB.UTF-8, que es una de las opciones 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

Varios de los sistemas Linux más capaces que uso parecen tener una opción equivalente, pero observo que en Linux el nombre es ligeramente diferente:

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

Esto me hace preguntarme: cuando entro sshen una máquina Linux desde mi Mac, y reenvía todas mis LC_*variables con ese sufijo 'UTF-8', ¿esa máquina Linux comprende lo que se le pide? ¿O simplemente se está volviendo a otro lugar?

editar: Aquí hay un ejemplo de lo que me refiero:

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

En cualquier caso, ¿cuál es el mecanismo detrás de su comportamiento, y depende de una configuración particular (por ejemplo, ¿veré el mismo comportamiento en un sistema basado en BusyBox que en uno basado en GNU)?

— vacas
fuente

explicación allí: superuser.com/questions/999133/... (respuesta de grawity). Entonces, desde BSD a Linux no hay problema. Desde Linux (si define utf8 en lugar de UTF-8) hasta BSD, puede haber un problema.

— AB

Respuestas:

Es una pregunta interesante, pero creo que puede haber una idea errónea sobre cómo se configuran las variables. Cuando se inicia una sesión de shell segura ( ssh remotehost), lo que sucede en el otro extremo es una instanciación de un nuevo shell con un entorno separado. Esa es una forma elegante de decir que el servidor inicia un nuevo shell. Ese nuevo shell puede o no configurarse con la misma configuración regional que su shell local original.

P.ej

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

Para demostrar esto, configuré la configuración regional en el shell remoto para Norwegian agregando las siguientes líneas al archivo ~ / .bash_profile:

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

Del mismo modo, tendrá que configurar el entorno en el shell remoto para hacer lo mismo. Por supuesto, otros shells leen diferentes archivos de inicio como ~ / .zprofile para el shell Z.

La idea errónea que sospeché radica en que las variables locales (configuraciones) no se envían de ninguna manera. El shell remoto tiene su propia configuración. Para enumerar los idiomas disponibles en el host remoto, ya sea un shell BusyBox minimalista o un sistema operativo GNU completo, use el localecomando con el -ainterruptor (como se indica en la pregunta). Cualquiera de las líneas impresas se puede usar como una configuración regional para ese entorno.

En cuanto a la primera pregunta, la configuración regional predeterminada con la que comienza cualquier shell generalmente se configura en un lugar central como / etc / profile. La mayoría de los shells de inicio de sesión leen este archivo al inicio.

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

Las cosas locales definitivamente se reenvían. /etc/ssh_configen cada máquina que he visto define eso LANGy LC_*se envía a todos los hosts de forma predeterminada, y ssh -vrevela varias líneas como debug1: Sending env LC_ALL = en_GB.UTF-8. Por supuesto, si el perfil de la cáscara en el otro extremo anula posteriormente que, eso es otra cosa - pero en algunos de mis máquinas, que no es el caso

— vacas

PD: He actualizado mi publicación original con quizás una mejor ilustración de lo que me refiero

— kine

Es cierto que nunca he visto esto. ¿Las máquinas a las que te refieres, Debian? Quizás esto explicará el mecanismo de reenvío ssh env. Sigo pensando que los nombres de las configuraciones regionales deben coincidir exactamente, porque no se supone que la configuración regional sea lo suficientemente inteligente como para resolver esto. La razón por la cual las cadenas son diferentes es porque la biblioteca C es diferente para máquinas basadas en BSD y GNU / Linux. No se conocen el uno al otro. Pero tal vez estoy siendo demasiado escéptico y el programa local tiene una forma de ajustar esto automáticamente.

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

Esa es la parte por la que tenía curiosidad: el sshreenvío es incidental, es solo el contexto de por qué mi configuración regional está configurada de la manera en que está. Simplemente no sé cómo determinar qué está haciendo realmente el shell en el otro extremo; por lo general, no recibo errores al intentar configurar la configuración regional (aunque a veces lo hago en dispositivos integrados), y la entrada / visualización de texto Unicode parece funciona normalmente (?), pero la configuración regional que estoy usando obviamente no está presente en el sistema. La mayoría de los dispositivos Linux a los que me conecto están basados en Debian o Ubuntu, mientras que otros están basados en uClibc / BusyBox (dispositivos de red, etc.).

— kine

¿El nombre del soporte UTF-8 también es ligeramente diferente en diferentes sistemas para el siguiente comando?

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

Si encuentra problemas extraños relacionados con la configuración regional, puede ser útil decirle al cliente SSH que no envíe esas LC_*variables comentando SendEnv LANG LC_*en /etc/ssh_config(consulte, por ejemplo, Solucionar problemas y terminal SSH UTF-8 de Mac OS X Lion en OS X Lion: puede No escriba åäö en la máquina remota ).

Otro enfoque de solución es este:

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