Przenośność ustawień regionalnych UTF-8 (i ssh)

Sporo czasu spędzam sshna różnych komputerach, z których wszystkie są różne (niektóre są osadzone, niektóre uruchamiają Linuksa, niektóre uruchamiają BSD i tak dalej). Jednak na moich lokalnych komputerach używam OS X, który oczywiście ma obszar użytkownika oparty na BSD. Moje ustawienia regionalne na tych komputerach to en_GB.UTF-8, co jest jedną z dostępnych opcji:

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

Niektóre z bardziej wydajnych systemów Linux, których używam, wydają się mieć równoważną opcję, ale zauważam, że w systemie Linux nazwa jest nieco inna:

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

To mnie zastanawia: kiedy wchodzę sshna maszynę z Linuksem z mojego komputera Mac i przesyła ona wszystkie moje LC_*zmienne z sufiksem „UTF-8”, czy ta maszyna z Linuksem rozumie nawet, o co jest proszona? A może po prostu wraca do innej lokalizacji?

edycja: Oto przykład tego, o czym mówię:

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

W obu przypadkach, jaki jest mechanizm jego zachowania i czy jest on zależny od jakiejkolwiek konkretnej konfiguracji (np. Czy zobaczę takie samo zachowanie w systemie opartym na BusyBox, jak w systemie opartym na GNU)?

To interesujące pytanie, ale myślę, że może istnieć nieporozumienie na temat konfiguracji zmiennych. Kiedy inicjowana jest bezpieczna sesja powłoki ( ssh remotehost), na drugim końcu dzieje się tworzenie nowej powłoki z oddzielnym środowiskiem. To fantazyjny sposób powiedzenia, że ​​serwer uruchamia nową powłokę. Ta nowa powłoka może być skonfigurowana z tymi samymi ustawieniami narodowymi co oryginalna powłoka lokalna.

Na przykład

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

Aby to zademonstrować, skonfigurowałem ustawienia regionalne w zdalnej powłoce dla Norwegian, dodając następujące wiersze do pliku ~ / .bash_profile:

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

Podobnie będziesz musiał skonfigurować środowisko na zdalnej powłoce, aby zrobić to samo. Oczywiście inne powłoki odczytują różne pliki startowe, takie jak ~ / .zprofile dla powłoki Z.

Podejrzewam, że nieporozumienie polega na tym, że lokalne zmienne (ustawienia) nie są w żaden sposób przekazywane. Zdalna powłoka ma własne ustawienia. Aby wyświetlić listę dostępnych języków na zdalnym hoście, czy to minimalistyczna powłoka BusyBox, czy pełnoprawny system GNU, użyj localepolecenia z -aprzełącznikiem (jak wspomniano w pytaniu). Każda z drukowanych linii może być używana jako ustawienie regionalne dla tego środowiska.

Jeśli chodzi o pierwsze pytanie, domyślne ustawienia narodowe, od których zaczyna się jakakolwiek powłoka, są zwykle konfigurowane w centralnym miejscu, takim jak / etc / profile. Większość powłok logowania odczytuje ten plik podczas uruchamiania.

Czy nazwa obsługi UTF-8 jest nieco inna w różnych systemach dla następujących poleceń?

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

Jeśli napotkasz dziwne problemy związane z locale, może pomóc poinformować klienta SSH aby nie wysyłać tych LC_*zmiennych przez zakomentowanie SendEnv LANG LC_*w /etc/ssh_config(patrz, na przykład, Fixing SSH UTF-8 Problemy Mac OS X Lion jest i terminali w OS X Lion: Można pisz åäö na zdalnym komputerze ).

Innym rozwiązaniem jest:

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