Переносність локалізації UTF-8 (і ssh)


9

Я багато часу проводжу sshпід різними машинами, всі вони різні (деякі вбудовані, деякі запускають Linux, деякі запускають BSD та ін.). На власних локальних машинах, однак, я використовую OS X, яка, звичайно, має поле користування на основі BSD. Моя мова на цих машинах встановлена ​​на en_GB.UTF-8, що є одним із доступних варіантів:

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

Деякі з більш спроможних систем Linux, які я використовую, мають еквівалентний варіант, але зауважую, що в Linux назва трохи відрізняється:

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

Це змушує мене замислитись: коли я перебуваю sshна машині Linux з мого Mac, і він пересилає всі мої LC_*змінні з цим суфіксом 'UTF-8', чи машина Linux навіть розуміє, що про неї запитують? Або це просто повернення до якогось іншого місця?

редагувати: Ось приклад того, про що я маю на увазі:

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

В будь-якому випадку, який механізм стоїть за його поведінкою, і чи залежить це від будь-якої конкретної настройки (наприклад, чи я побачу таку саму поведінку в системі, що базується на BusyBox, як і в GNU)?


пояснення там: superuser.com/questions/999133/… (відповідь із шаленості). Так що від BSD до Linux немає жодних проблем. З Linux (якщо він визначає utf8 замість UTF-8) до BSD, може виникнути проблема.
AB

Відповіді:


0

Це цікаве питання, але я думаю, що там може виникнути помилкове уявлення про те, як налаштовані змінні. Коли ініційований сеанс захищеної оболонки ( ssh remotehost), те, що відбувається на іншому кінці, - це створення нової оболонки з окремим середовищем. Це химерний спосіб сказати, що сервер починає свіжу оболонку. Ця нова оболонка може бути або не може бути налаштована з тим же локалом, що і ваша початкова локальна оболонка.

Напр

гьо: ~
$ echo `locale | grep LANG` ::` дата`
LANG = en_US.UTF-8 :: понеділок 3 грудня 07:04:00 CET 2012

$ ssh flode
flode: ~
$ echo `locale | grep LANG` ::` дата`
LANG = nb_NO.UTF-8 LANGUAGE = nb_NO.UTF-8 :: ma. 03. дес. 06:59:33 +0100 2012

Щоб продемонструвати це, я встановив локаль на віддаленій оболонці для норвезької мови, додавши до файлу ~ / .bash_profile такі рядки:

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

Так само вам доведеться налаштувати середовище на віддаленій оболонці, щоб зробити те саме. Звичайно, інші оболонки читають різні файли запуску, такі як ~ / .zprofile для оболонки Z.

Помилкове уявлення, яке я підозрював, полягає в тому, що локальні змінні (настройки) жодним чином не передаються. Віддалена оболонка має власні налаштування. Для того, щоб перелічити доступні мови на віддаленому хості, будь то мінімалістична оболонка BusyBox або повномасштабна ОС GNU, використовуйте localeкоманду з -aперемикачем (як зазначено в питанні). Будь-яка з друкованих рядків може використовуватися як локальний параметр для цього середовища.

Що стосується першого питання, локальне місце за замовчуванням, з якого починається будь-яка оболонка, зазвичай налаштоване в центральному місці, наприклад / etc / profile. Більшість оболонок для входу читають цей файл при запуску.


2
Локальні речі, безумовно, пересилаються. /etc/ssh_configна кожній машині, яку я коли-небудь дивився, визначає це LANGі LC_*буде надіслано всім хостам за замовчуванням, і ssh -vвиявляється кілька рядків, як debug1: Sending env LC_ALL = en_GB.UTF-8. Звичайно, якщо профіль оболонки на іншому кінці згодом відміняє це, то інша річ - але на деяких моїх машинах це не так
kine

PS: Я оновив свій початковий пост, можливо, кращою ілюстрацією того, про що я маю на увазі
Kine

Справді, я цього ніколи не бачив. Машини, на яких ви посилаєтесь, Debian? Можливо, це пояснить механізм переадресації ssh env. Я все ще думаю, що імена локалів повинні точно збігатися, тому що локали не повинні бути досить розумними, щоб зрозуміти це. Причина, чому рядки різні, полягає в тому, що бібліотека C відрізняється для машин на базі BSD та GNU / Linux. Вони не знають один про одного. Але, можливо, я занадто скептично налаштований, і програма локальної програми має спосіб автоматичного налаштування цього.
Ярослав Рахматуллін

Це та частина, про яку мені було цікаво - sshекспедиторські речі є випадковими, це лише контекст, чому мій мовний параметр встановлений таким, яким він є. Я просто не знаю, як визначити, що насправді робить оболонка на іншому кінці - я, як правило, не отримую помилок під час встановлення локалі (хоча я іноді це роблю на вбудованих пристроях), і, як видається, введення / відображення тексту Unicode працюють нормально (?), але локаль, яку я використовую, очевидно, немає в системі. Більшість пристроїв Linux, до яких я підключаюсь, базуються на Debian або Ubuntu, а інші - на uClibc / BusyBox (мережеві пристрої та ін.).
кін

0

Чи назва підтримки UTF-8 дещо відрізняється в різних системах для наступної команди?

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

Якщо ви зіткнулися з дивними проблемами локалі , пов'язані, це може допомогти сказати клієнту SSH , щоб не відправляти ці LC_*змінні закоментувавши SendEnv LANG LC_*в /etc/ssh_config(см, наприклад, Закріплення SSH UTF-8 Issues Mac OS X Lion в і Terminal в OS X Lion: балончик не пишу åäö на віддаленій машині ).

Ще один підхід до рішення:

# 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 #
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.