LC_MONETARY="ru_RU.KOI8-R"

LC_MESSAGES="ru_RU.KOI8-R"

LC_PAPER="ru_RU.KOI8-R"

LC_NAME="ru_RU.KOI8-R"

LC_ADDRESS="ru_RU.KOI8-R"

LC_TELEPHONE="ru_RU.KOI8-R"

LC_MEASUREMENT="ru_RU.KOI8-R"

LC_IDENTIFICATION="ru_RU.KOI8-R"

LC_ALL=

alekseybb@wsvm02:~> grep ^RC_LANG /etc/sysconfig/language

RC_LANG=ru_RU.MAC-CYRILLIC

Как видно из протокола сеанса, командная оболочка запустилась в локали клиента. Произошло это благодаря тому, что в параметрах сервера ssh указано экспортировать переменные среды клиента:

wsvm02:~ # grep ^AcceptEnv /etc/ssh/sshd_config

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT

AcceptEnv LC_IDENTIFICATION LC_ALL

А в параметрах клиента, аналогично, передавать переменные среды на удаленную сторону:

wsalekseybb:~ # grep ^SendEnv /etc/ssh/ssh_config

SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT

SendEnv LC_IDENTIFICATION LC_ALL

Но если попытаться подключиться к компьютеру в локали ru_RU.MAC-CYRILLIC с помощью PyTTY из-под MS Windows, то ничего хорошего не получится, так как там нет возможности ни передать переменные программной среды, ни прямо указать перекодировку с MAC-CYRILLIC.

Надо заметить, что в приложениях, не поддерживающих POSIX-локали, бывают вообще странные ситуации, вроде той, что сообщает wine при запуске некоторых абстрактно написанных программ:

fixme: msvcrt:MSVCRT_setlocale : Codepage only locale not implemented

Дословно: локаль, определяемая только кодовой таблицей, не реализована. В свете того, что по кодировке символьного потока вообще нельзя установить тип локали, приведенное выше сообщение можно понимать, как своего рода юмор.

Подведем итоги

В общем случае не представляется сложным настроить рабочую станцию GNU/Linux в любой из желаемых локалей. Как было продемонстрировано на примере SuSE Linux 10.0, который не является кириллически толерантным, что указано в предупреждении инсталлятора, даже такой дистрибутив поддается настройке. Казалось бы, отечественные дистрибутивы должны все описанное в статье иметь как встроенный сервис. Но этого не наблюдается. На Руси с древности повелось так, что народ учили грамоте то всякие «пришлые греки», то «ушлые варяги». Складывающаяся вокруг компьютерных кодировок ситуация следует исторической традиции. Очередные заморские гуру, в который раз предлагают отказаться от всего, что было ранее проверено и внедрено, и принять от них новую чудодейственную «пилюлю». Ожидаемо, после того как четыре зарубежные компании создали четыре взаимоисключающие способа кодирования кириллической информации, полностью игнорируя ту, что была создана независимыми отечественными разработчиками, в среде пользователей должен сформироваться иммунитет к языковым авантюрам. Тем более что, как продемонстрировано выше, единого подхода к работе с локалями не наблюдается вовсе, то есть появление новой локали закономерно приведет к новым хлопотам и проблемам с программами. Но лишь один из ведущих российских разработчиков – ASPLinux – признает сложившуюся ситуацию и предлагает набор локалей и кодировок на выбор (все из перечисленного, кроме экзотической кодировки Mac и устаревшей cp866, в версии 10 ASPLinux). А вот дистрибуция ALT Linux, копируя западный подход, с версии 3.0 полностью переходит в ru_RU.UTF-8. Причем рекомендации по «откату» на привычную KOI8R выкладываются в Сеть синхронно с появлением этой искусственно созданной «проблемы» [8]. Вероятно, тщательная кириллизация Linux не только стала казаться неактуальной для некоторых пользователей, но даже и не считается обязательным качеством национальной продукции у некоторых разработчиков.