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

9

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)?

bydło
źródło
wyjaśnienie tam: superuser.com/questions/999133/… (odpowiedź grawitacji). Więc od BSD do Linuksa nie ma problemu. Od Linuksa (jeśli definiuje utf8 zamiast UTF-8) do BSD, może występować problem.
AB

Odpowiedzi:

0

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.

Ярослав Рахматуллин
źródło
2
Ustawienia regionalne są zdecydowanie przekazywane. /etc/ssh_configna każdym komputerze, jaki kiedykolwiek patrzył na Definiuje że LANGi LC_*być wysyłane do wszystkich hostów domyślnie i ssh -vujawnia kilka wierszy jak debug1: Sending env LC_ALL = en_GB.UTF-8. Oczywiście, jeśli profil powłoki na drugim końcu później przesłoniłby to, to inna sprawa - ale na niektórych moich komputerach tak nie jest
kine
PS: Zaktualizowałem swój oryginalny post, być może lepszą ilustracją tego, o czym mówię
kine
Trzeba przyznać, że nigdy tego nie widziałem. Maszyny, o których mówisz, Debian? Być może to wyjaśni mechanizm przekazywania env ssh. Nadal uważam, że nazwy ustawień regionalnych muszą być dokładnie takie same, ponieważ ustawienia regionalne nie powinny być wystarczająco inteligentne, aby to rozgryźć. Powodem, dla którego łańcuchy są różne, jest to, że biblioteka C jest inna dla maszyn opartych na BSD i GNU / Linux. Nie znają się nawzajem. Ale być może jestem zbyt sceptyczny, a program ustawień regionalnych ma sposób na automatyczne dostosowanie tego.
Ярослав Рахматуллин
To była część, która mnie ciekawi - sshprzekazywanie jest przypadkowe, to tylko kontekst, dla którego moje ustawienia regionalne są ustawione tak, jak są. Po prostu nie wiem, jak ustalić, co faktycznie robi powłoka na drugim końcu - zwykle nie dostaję błędów, próbując ustawić ustawienia regionalne (chociaż czasami robię to na urządzeniach osadzonych), a tekst / kod Unicode wydaje się działają normalnie (?), ale ustawienia narodowe, których używam, oczywiście nie są obecne w systemie. Większość urządzeń Linux, z którymi się łączę, oparta jest na Debianie lub Ubuntu, podczas gdy inne są oparte na uClibc / BusyBox (urządzenia sieciowe i inne).
kine
0

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 #
karly
źródło