Если бы в
нашем сериале о Linux принято было сопровождать каждую главу зазывными
заголовками с претензией на художественность, нынешнюю, юбилейную
тринадцатую, я с наслаждением поименовал бы так: "Собираем вещички".
Речь ни в коем случае не пойдёт о приостановке изучения системы.
Нет-нет! Просто, поработав со свежеустановленной поверх предыдущей
версией Red Hat Linux 9, я пришёл к твёрдому выводу: надо мигрировать.
Полноценно мигрировать на "девятку", а не ограничиваться модернизацией.
Причина - в том, как реализована в новом дистрибутиве от Red Hat
поддержка русского языка.
Здесь
я допущу небольшое лирическое отступление. Сторонники российских (а
также украинских, белорусских и т. п.) дистрибутивов Linux приводят
множество аргументов в поддержку того, почему предпочитаемые ими
системы хороши именно для местного пользователя. Аргументов, априори
вовсе не очевидных. Ведь зачастую в качестве основы для таких продуктов
берётся известный дистрибутив международного класса (тот же Red Hat), в
нём решаются силами местных программистов все вплоть до мельчайших
проблемы с локализацией, иногда добавляются ещё несколько пакетов - и
новинка для внутреннего рынка готова. Соответственно, если в одном из
пакетов исходного дистрибутива выявляется уязвимость, то полноценная
"заплатка" для дочернего, локального варианта Linux появится,
очевидно, с некоторым запозданием. Так что хотя с точки зрения удобства
пользования местные версии Linux выигрывают у исходных англоязычных, к
ним можно предъявить некоторые претензии в области надёжности и
устойчивости к атакам. И лично мне этот аргумент виделся очень
существенным - до самого последнего времени. До того, как я принялся
модернизировать Red Hat Linux 7.3 до девятой версии. Конец лирического
отступления.
Как
известно, большой проблемой русского Интернета - и вообще
компьютеризации Руси - была и остаётся неразбериха с кодировками
кириллицы. Я не буду сейчас вспоминать, что было раньше и что стало
потом, благо литературы по теме имеется масса. Сформулирую основное: в
Windows-системах безраздельно царствует кодировка cp1251, Linux же и
*NIX, включая всевозможные версии *BSD, до сих пор оставались вотчиной
старой доброй KOI8-R. За долгие годы сторонники свободного ПО прекрасно
научились справляться с этим, разработав множество удобных утилит для
перекодировки - а широкая популярность веб-сервера Apache привела к
тому, что множество страниц Рунета хранятся на поддерживающих сайты
компьютерах именно в KOI8. Однако времена меняются: именно компания
Red Hat, начиная с восьмой версии своего дистрибутива, сделала в
системе стандартом универсальную кодировку UTF8.
Универсальность
- это великолепно. Когда UTF8 войдёт во всеобщий обиход, проблемы со
"странными значками", "закорючками", "вопросиками" и "квадратиками" в
сообщениях исчезнут без следа. В одной и той же системе закодированы
все алфавиты мира, включая азиатские, - имеется даже проект по
внедрению в стандарт UTF египетских иероглифов, благо знакомест
хватает. Но вот какая тонкость: светлые времена, о которых с восторгом
повествуют поборники UTF, пока не наступили. И когда наступят - неясно.
Точнее, ясно: ровно тогда, когда эту систему кодирования поднимет на
щит Microsoft. А пока компания Red Hat решила, что раз будущее всё
равно наступит, то незачем ждать его сложа руки. Нужно взять - и
приблизить. Всё равно подавляющее большинство пользователей продукта
компании англоязычны, а для них что UTF, что ASCII - по большому
счёту, разницы нет.
Но
для нас - есть, и притом существенная. Что нужно для полноценной работы
с компьютером, пользователь которого является носителем отличного от
английского языка? Точнее - языка, где для записи информации
употребляются буквы, отличные от базовых 26 английских? Такому
пользователю важнее всего возможность создавать документы на родном
языке, без проблем открывать и читать уже созданные такие документы, и,
конечно, свободно переключаться между универсальной и местной
клавиатурными раскладками. Простейшие требования, верно? В Windows
никому и в голову не приходит, что тут могут возникать какие-либо
сложности.
Строго
говоря, до настоящего времени у меня никаких проблем с кодировками при
использовании Red Hat Linux не возникало. Русификация и консоли, и
графического режима (особенно в оконном менеджере KDE) была уверенно
реализована, хорошо описана и тоже воспринималась как нечто само собой
разумеющееся. Вот в Red Hat Linux 5.0, помнится, с этим дело обстояло
не так просто... Но воды с той поры утекло немало, и всё было бы
замечательно, если бы не возникшая перед нами сейчас необходимость:
перейти при модернизации системы с версии 7.3, где в качестве русской
кодировки по умолчанию применялась KOI8-R, на девятую версию с её
прогрессивной UTF.
Загвоздка
же в том, что при апгрейде многое в системе остаётся прежним. В
частности, если вы активно работали с русским текстом в консольных
редакторах (или сохраняли лог-файлы ICQ-клиентов вроде licq в домашней
директории), прочитать записанный в KOI8-R текст теперь будет
трудновато. К тому же, помимо перехода к UTF, начиная с версии 8.0,
Red Hat "обкатывает" на пользователях ещё одно новшество: совмещение
двух популярнейших оконных менеджеров, KDE и Gnome. Переработанный
кудесниками в красных шапках графический интерфейс Bluecurve является
синтезом наиболее сильных сторон обоих конкурирующих продуктов.
(Поскольку оба продукта - свободно распространяемые и с открытым кодом,
становится возможным, как видим, и такое непредставимое в мире бизнеса
явление, как их жизнеспособная контаминация). Побочной стороной этого
слияния является то, что - как в случае моей домашней системы - никуда
не девшиеся прежние настройки оконного менеджера (именно в части
управления раскладкой клавиатуры) начинают конфликтовать с новыми.
Суммирую:
после апгрейда Red Hat Linux 7.3 до версии 9 я столкнулся с достаточно
серьёзными сложностями в работе, которых - проводи я нормальную
установку системы - попросту не возникло бы. Поэтому на сей раз мы
рассмотрим, каким образом осуществить полноценную миграцию на новую
систему. И начнём с самого начала.
С
самого начала, сразу после первой перезагрузки, последовавшей за
апгрейдом, в системной консоли стали наблюдаться, скажем так, некоторые
несуразности. А именно: раньше при старте системы отдельные сообщения о
запуске её компонент отображались с использованием кириллицы (и
разумеется. В KOI). Что-то вроде
Запускается sendmail [ OK ]
Теперь
же вместо каждой из букв кириллицы на экране отображалась "у-умляут" -
судя по всему, вследствие того, что в наследство "модернизированной"
системе с UTF достались некоторые утилиты, всё ещё пытающиеся
организовать вывод в KOI. Тем не менее, с латиницей всё было в порядке,
и после запуска X Window System я с облегчением увидел, что отображение
кириллицы (в заголовках окон, названиях разделов и программ в меню
запуска и т. п.) там работает. За исключением маленькой детали:
отказало переключение с русской клавиатуры на английскую и обратно.
Нет,
соответствующая опция из Центра управления KDE никуда не делась. Вот
только, судя по всему, при слиянии KDE с Gnome в Red Hat получили
продукт, не полностью совместимый с предшествующими "полноценными"
версиями этих графических оболочек. По крайней мере - в данной
конкретной области, связанной с локализациями, и в особенности с
локализациями приложений. К тому же, прочесть элементарный текстовый
файл, набранный когда-то в консоли кириллицей в KOI8-R, я уже не мог ни
при помощи less, ни с использованием vi или cat.
Строго
говоря, ничего удивительного: при инсталляции система вовсе не обязана
каждую имеющуюся на винчестере запись в KOI (будь то рабочий текстовый
файл или стандартное сообщение в локализованной ранее программе)
переводить в UTF. Хотя... Быть может, вариант безболезненного апгрейда
будет осуществлён в одном из наших местных дистрибутивов, берущих за
основу продукты Red Hat? А может, он уже осуществлён, просто мне об
этом ничего не известно? Знаю пока только, что очень хочу добиться
нормального обращения с кириллицей именно в Red Hat Linux 9, и сейчас
вместе с вами этого таки добьюсь. По крайней мере, в пределах,
необходимых для дальнейшей полноценной и безболезненной миграции на
полный UTF.
Разумеется,
я не первым столкнулся с подобной проблемой: переход на UTF Red Hat
произвела ещё в полугодичной примерно давности версии 8.0. И в качестве
одного из возможных рецептов действий в такой ситуации гуру предлагают
отказ от перехода как такового - иными словами, возвращение к
использованию KOI. "Даунгрейд" одной из компонент системы, если можно
так выразиться. Дабы избежать, в частности, неприятных последствий
"выборочной" замены KOI на UTF.
И
всё-таки я предпочту другой путь, что, кстати, имеет смысл и для всех
начинающих: осуществить грамотную миграцию на UTF и работать отныне
уже с ней. Потому что за универсальной кодировкой всё-таки будущее. Но
чтобы к этому будущему приблизиться, сперва нужно хоть как-то привести
в порядок текущий вид отображения символов в консоли. Многие операции,
связанные с сохранением данных, предпочтительнее производить под
непосредственным личным контролем - "ручками", как говорят всё те же
гуру. Для пущей уверенности, что всё сделано правильно.
Итак,
прежде всего справимся с пренеприятнейшими "умляутами", заполонившими
вместо русских букв нашу консоль. За то, какой именно набор символов
используется при выводе консольных сообщений, ответственны несколько
переменных окружения, задающихся в файле /etc/sysconfig/i18n. Название
файла, кстати, - весьма остроумное сокращение от слова
"internationalization": 18 - это число букв между начальной i и
конечной n.
Параметр
LANG определяет так называемую локаль (locale) - режим, в котором
работает выводящий символы на экран драйвер консоли. Здесь, как и можно
ожидать после апгрейда системы, установлено значение "ru_RU.UTF-8". Тем
не менее, среди поддерживаемых (SUPPORTED) кодировок наличествует и
ru_RU.koi8r. Однако, как можно убедиться, в случае системных сообщений
"по-русски" это не помогает. Можно предположить, что корректно будет
обрабатываться вывод символов в том случае, если их кодировка чётко
указана - средствами производящего вывод приложения, скажем (текстового
редактора или ещё какого-либо). А со стороны системных приложений,
русификация которых не была обновлена по сравнению с предыдущей
версией, такого сюрприза консоль явно не ожидает. Дело ещё и в том, что
переменная SYSFONT указывает не на бывший ранее привычным консольный
русифицированный фонт (скажем, Cyr_a8x16), а на новомодную UTF-новинку
latarcyrheb-sun16.
Как
можно судить по наименованию данного системного шрифта, ему по силам
отображать одновременно символы латинского, арабского, кириллическего
и еврейского алфавитов. (Тут, правда, возникает закономерный вопрос -
будет ли автоматически меняться направление письма при переходе с
кириллицы на арабский, скажем, но пока это нас интересует чисто
академически). Однако при попытке отобразить средствами данного шрифта
закодированный в KOI текст ничего путного на экране видно не будет.
Дополнительную путаницу вносит установка таблицы перекодировки символов
(Application Character Map, ACM) для перевода входного потока символов
во внутреннюю кодировку ядра - Unicode: SYSFONTACM="utf8". В общем,
первое, что я сделал, это избавился от пережитков прошлого в виде
упоминания о кодировке KOI, упорядочил задание переменной SUPPORTED и
убрал сомнительный параметр SYSFONTACM. В итоге на консоль вернулись
русские буквы там, где их выводили системные приложения.
Правда,
с несистемными приложениями - а именно, банальными текстовыми файлами в
кодировке KOI - всё было не так просто. Ни элементарная команда cat,
ни less, more или vi не в состоянии были отобразить на консоли в
сколько-нибудь пригодном для чтения виде их содержимое.
Больше
того - при попытке просмотреть содержимое подмонтированных
vfat-разделов вместо русских букв в названиях файлов снова запестрели
вопросительные знаки. Однако с этой напастью справиться было несколько
проще. Я ведь знал, что изначально для их отображения применялась
кодировка KOI!
Файл /etc/fstab я незамедлительно подправил - учитывая, что выводить символы на экран мне теперь надо в UTF.
Затем
потребовалось (чтобы не перезагружаться лишний раз) отмонтировать
Windows-разделы, после чего снова присоединить их с использованием
нового /etc/fstab. Делается это серией команд
umount /mnt/c
umount /mnt/d
mount -a
Обратите,
кстати говоря, внимание: опции для монтирования внешних носителей (CD и
DVD) также включают у меня указание на то, что записанные там с
применением кириллицы имена файлов следует воспринимать как набранные
изначально в Windows-кодировке. Сделано это потому, что под Linux я
никогда не использую кириллицу в наименованиях файлов и каталогов, а
Windows-диски, напротив, читаю часто (взять хотя бы цифровые приложения
к компьютерным журналам). Так что опасности ошибиться нет. Но в
принципе, с этой опцией надо обращаться осторожно - и уж во всяком
случае постоянно помнить, что она включена и работает.
Следующим
шагом, который я совершил по пути тотального перехода на универсальную
кодировку, стал перевод текстовых кириллических файлов в UTF. У вас,
если ваше знакомство с Linux ещё не вошло в стадию активного увлечения,
наверняка не так уж много ценной информации содержится в таком виде. А
для меня очень важно было сохранить свои ICQ-логи. Которые программа
licq, входящая с некоторых пор в стандартный комплект поставки
дистрибутивов от Red Hat, хранит в виде как раз простых текстовых
файлов в базовой системной кодировке. Стало быть, они мне после
апгрейда оказались недоступны.
Напомню,
что в случае Linux хранить чувствительную информацию в виде открытого
текста не столь опрометчиво, как под Windows: системные установки по
умолчанию блокируют доступ к содержимому вашей домашней директории кого
бы то ни было (за исключением суперпользователя, конечно). И поскольку
текст хранится в KOI, в данном случае мне нужно было всего лишь
перекодировать его из исходного вида в UTF. Что я и сделал посредством
утилиты с незамысловатым наименованием recode. Подробности, как
водится, доступны по команде man recode.
Лог-файлы
ICQ-клиента licq хранятся в подкаталоге .licq/history/ , и все они - я
это знал точно - кодированы именно в KOI. Поэтому для того, чтобы
архив сделался снова доступным, достаточно было команды
recode koi8-r..utf-8 .licq/history/*
Точно
таким же способом я вернул себе возможность читать ещё несколько файлов
с кириллическим текстом. Между прочим, как выяснилось при изучении
соответствующей документации, в комплект поставки Red Hat Linux 9
входит-таки просмотрщик текста, позволяющий хоть как-то отображать не
читаемую иными способами кодировку KOI. Эта программа называется lv, и
если теперь вернуть наш тестовый файл в исходное состояние командой
recode utf-8..koi8-r test.txt
то
ни less, ни more прочесть его содержимое по-прежнему не позволят, а вот
lv вместо кириллицы отобразит для каждой русской буквы определённое
латинское соответствие.
Когда-то
давным-давно именно так выглядели в Linux-консоли почтового сервера, не
поддерживавшей кириллицы в принципе, приходившие в KOI письма... Ах,
молодость, молодость...
Однако
не время предаваться приятным воспоминаниям. Время заняться полезным
делом: приготовить личные данные из домашней директории, а также файлы
системных настроек - плоды усердных наших трудов - к сохранению в свете
предстоящей полноценной переустановки системы. Строго говоря,
форматировать раздел /home я не собираюсь, но бережёного бог бережёт -
это во-первых, а во-вторых - с методической точки зрения действия, в
которых мы будем вскоре практиковаться, без сомнения окажутся полезными
при работе с системой в дальнейшем.
К следующей статье
К оглавлению
|
|
