Portabilidade de localidade UTF-8 (e ssh)

Eu passo muito do meu tempo sshem várias máquinas, todas diferentes (algumas são incorporadas, outras rodam Linux, outras rodam BSD etc.). Em minhas próprias máquinas locais, no entanto, eu uso o OS X, que obviamente possui uma área de usuário baseada no BSD. Minha localidade nessas máquinas é definida como en_GB.UTF-8, que é uma das opções disponíveis:

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

Vários dos sistemas Linux mais capazes que eu uso parecem ter uma opção equivalente, mas observo que no Linux o nome é um pouco diferente:

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

Isso me faz pensar: quando eu entro sshem uma máquina Linux do meu Mac, e encaminha todas as minhas LC_*variáveis com o sufixo 'UTF-8', essa máquina Linux entende o que está sendo solicitado? Ou está apenas voltando a outro local?

edit: Aqui está um exemplo do que estou me referindo:

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

Em qualquer um dos casos, qual é o mecanismo por trás de seu comportamento e depende de qualquer configuração específica (por exemplo, vou ver o mesmo comportamento em um sistema baseado no BusyBox e em um baseado no GNU)?

— vacilar
fonte

explicação lá: superuser.com/questions/999133/… (resposta do grawity). Então, do BSD ao Linux, não há problema. Do Linux (se definir utf8 em vez de UTF-8) para BSD, pode haver um problema.

— AB

Respostas:

É uma pergunta interessante, mas acho que pode haver um equívoco sobre como as variáveis são configuradas. Quando uma sessão segura do shell é iniciada ( ssh remotehost), o que acontece na outra extremidade é a instanciação de um novo shell com um ambiente separado. Essa é uma maneira elegante de dizer que o servidor inicia um shell novo. Esse novo shell pode ou não ser configurado com o mesmo código de idioma que o seu shell local original.

Por exemplo

geee: ~
$ echo `locale | grep LANG` ::` data`
LANG = pt_BR.UTF-8 :: Segunda-feira, 3 de dezembro 07:04:00 CET 2012

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

Para demonstrar isso, configurei o código do idioma no shell remoto para o norueguês adicionando as seguintes linhas ao arquivo ~ / .bash_profile:

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

Da mesma forma, você precisará configurar o ambiente no shell remoto para fazer o mesmo. Obviamente, outros shells leem arquivos de inicialização diferentes, como ~ / .zprofile para o shell Z.

O equívoco que eu suspeitava era que as variáveis locais (configurações) não são de forma alguma encaminhadas. O shell remoto tem suas próprias configurações. Para listar os idiomas disponíveis no host remoto, seja um shell BusyBox minimalista ou um sistema operacional GNU completo, use o localecomando com o -acomutador (conforme observado na pergunta). Qualquer uma das linhas impressas pode ser usada como uma configuração de localidade para esse ambiente.

Quanto à primeira pergunta, o código do idioma padrão com o qual qualquer shell inicia é geralmente configurado em um local central, como / etc / profile. A maioria dos shells de login lê esse arquivo na inicialização.

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

Material local é definitivamente encaminhado. /etc/ssh_configem todas as máquinas que eu já vi define isso LANGe LC_*ser enviado a todos os hosts por padrão, e ssh -vrevela várias linhas como debug1: Sending env LC_ALL = en_GB.UTF-8. Claro, se o perfil shell na outra extremidade substitui posteriormente que, isso é outra coisa - mas em algumas das minhas máquinas, que não é o caso

— vacas

PS: Eu atualizei meu post original, talvez com uma melhor ilustração do que eu estou me referindo

— vacas

É certo que eu nunca vi isso. As máquinas às quais você está se referindo, Debian? Talvez isso explique o mecanismo de envio de ssh. Eu ainda acho que os nomes dos códigos de idioma devem corresponder exatamente, porque o código de idioma não deve ser inteligente o suficiente para descobrir isso. A razão pela qual as strings são diferentes é porque a biblioteca C é diferente para máquinas baseadas em BSD e GNU / Linux. Eles não se conhecem. Mas talvez eu esteja sendo muito cético e o programa de localidade tenha uma maneira de ajustar isso automaticamente.

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

Essa é a parte pela qual eu estava curioso - o sshmaterial de encaminhamento é incidental, é apenas o contexto para o motivo pelo qual minha localidade está definida. Eu apenas não sei como determinar o que o shell do outro lado está realmente fazendo - eu normalmente não recebo erros ao tentar definir o local (embora às vezes eu faço isso em dispositivos incorporados), e a entrada / exibição de texto Unicode parece trabalho normalmente (?), mas o local que estou usando obviamente não está presente no sistema. A maioria dos dispositivos Linux aos quais eu conecto são baseados em Debian ou Ubuntu, enquanto outros são baseados em uClibc / BusyBox (dispositivos de rede, etc.).

— Kine

O nome do suporte UTF-8 é um pouco diferente em sistemas diferentes para o seguinte comando também?

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

Se você encontrar problemas relacionados à localidade estranhas, ele pode ajudar a informar o cliente SSH para não enviar essas LC_*variáveis comentando SendEnv LANG LC_*em /etc/ssh_config(ver, por exemplo, fixação do Mac OS X Lion SSH UTF-8 Questões e Terminal no OS X Lion: lata escreva åäö em uma máquina remota ).

Outra abordagem de solução é a seguinte:

# 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