![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
линукс-3
Решил сделать так, чтобы терминал (gnome-terminal), когда открывается, ставил себя в режим кодировки cp1251 по умолчанию.
А то он по умолчанию выбирает кодировку текущей локали, которая у меня вообще что-то дико-дифолтное. Пытаюсь выставить нужный LC_CTYPE - ничего не меняется. Тыкаюсь в меню - нигде нет чего-то типа "set default character coding". Думаю, может, в меню нет, но в конфигурации где-то сохраняется; лезу в .gconf/apps/gnome-terminal/ и читаю вручную .xml-файлы, ничего не нахожу (потом уже понял, что вместо чтения вручную надо идти в гномовский Application->System Tools->Configuration Editor). Смотрю на опции командной строки, нахожу опцию геометрии (чтобы запускать его сразу 80x40, а не 80x24, как по умолчанию, удобо), а кодировок нет.
Лезу в исходники gnome-terminal, блуждаю по encoding.c. terminal_encoding_init()... но нет, она создаёт список кодировок, но в этом списке никак не указано, какая текущая. grep encoding *.c . Ага, есть есть вызов terminal_widget_set_encoding() в terminal-window.c, внутри функции change_encoding_callback(). Очевидно, эта функция вызывается, когда я в меню меняю кодировку. Больше
terminal_widget_set_encoding нигде не вызывается, значит, change_encoding_callback() должен кто-то вызвать, когда программа начинает работать, чтобы поставить первоначальный дифолтный выбор. grep change_encoding_callback *.c . Ага, это происходит в fill_in_encodings_menu(), при инициализации меню. Где там ставится первоначальный выбор? charset = terminal_widget_get_encoding (w);
Т.е. первоначальную кодировку мы берём у библиотеки терминала. Смотрим, что это за функции terminal_widget_get_encoding() и terminal_widget_set_encoding(). Они определяются два раза: в terminal-widget-vte.c и terminal-widget-zvt.c . Смотрим на эти файлы - судя по всему, две разных имплементации виджета терминала. Та, которая zvt, попроще, и в terminal_widget_set_encoding() ничего не делает. Т.к. я могу менять кодировку, очевидно, мой gnome-terminal был построен с terminal-widget-vte.c, которая пользуется функциями vte_terminal_get_encoding() и vte_terminal_set_encoding(). Их в исходниках нет... это какая-то библиотека. Ищем vte... ага, есть такая библиотека гномовская, распакуем её исходники и посмотрим на эти функции. Из них становится понятно, что именно vte занимается перекодировкой входа/выхода, используя функции iconv. Откуда vte берёт первоначальный charset, к-й она использует? vte_terminal_get_encoding() читает кодировку из внутренней структуры терминала: terminal->pvt->encoding; значит, надо искать, кто её туда ставит. grep encoding *.c . Никто не трогает это поле, кроме vte_terminal_set_encoding(), странно; ага, эта функция принимает имя кодировки, но если вместо него передаётся NULL, то она вызывает g_get_charset(), и ставит кодировку, к-ю возвращает эта функция. Проверяем, где вызывается vte_terminal_set_encoding(), и да, действительно, во время инициализации терминала есть вызов с аргументом NULL. Т.е. надо искать, что такое g_get_charset(), похоже, что-то гномовское, но (grep g_get_charset *.c) в vte такой функции нет. find /usr/include -exec grep -q g_get_charset {} \; -print . Ага, /usr/include/glib-2.0/glib/gunicode.h .
Полезли распаковывать исходники glib2. g_get_charset() нашлась в glib/gutf8.c ; вначале вызывает _g_locale_charset_raw() - судя по имени, эта фунцкия наконец доходит до локали - но потом пользуется ещё каким-то внутренним кэшем для алиасов и канонизации имён кодировок, для чего использует g_utf8_get_charset_internal(), передавая ей полученную от _g_locale_charset_raw() строку и получая обратно имя кодировки, к-е сохраняет в кэше и возвращает наружу. Смотрим в _g_locale_charset_raw, она внутри glib/libcharset/libcharset.c ; ага, полезли кучи #define'ов на разные операционные системы и вызовы функций типа langinfo() и других функций локали. Здесь я ничего не добьюсь, чтобы разобраться, как мне грамотно выставить локаль, чтобы g_get_charset() получила 'cp1251', мне нужно лезть в исходники glibc, или искать грамотную документацию по локали (не-на-ви-жу). Смотрю в g_utf8_get_charset_internal(), и вот наконец приятный сюрприз:
const char *charset = getenv("CHARSET"); если это выставлено, она игнорирует то, что даёт локаль, и использует эту кодировку.
Уф. До свидания, исходники. "CHARSET=cp1251 gnome_terminal" - работает! Пытаюсь прописать это в шорткате, который я себе поставил для вызова терминала - фиг, говорит, не может запустить программу, значит, не пользуется он шеллом. Ищу где-то в опциях шортката (который здесь launcher называется) место для определения переменных среды - фигвам, хижина такая у эскимосов. Ладно, надоело: cat >~/scripts/gnome-terminal-cp1251
#!/bin/bash
export CHARSET=cp1251
exec gnome-terminal $*
Выставляю нужные разрешения на файл, ставлю его имя в launcher ($HOME он тоже не понимает, дубина... а где этому гному сказать, чтобы $HOME/scripts в $PATH добавил? Ладно, лень разбираться, в следующий раз, прописываю полный путь). Всё.
Это было такое экспериментальное описание "рабочего процесса".
Всё это сделать было быстрее, чем описать сейчас. Интересно, если бы я разбирался в локали, знал бы заранее, что можно CHARSET поставить? Или если бы в правильное место полез RTFMить, не пришлось бы по исходникам бегать? Очень вероятно, но, в конце концов, мне сам этот процесс нравится. Надо не увлекаться, однако, слишком легко много времени потерять.
Теперь программа терминала запускается с кодировкой cp1251, и mutt тоже (после того, как я прописал set charset=cp1251 в .muttrc), так что для чтение русских писем ничего дополнительного не надо делать.
no subject
Щас меня будут пинать ногами. Не бейте меня, дяденька, я тоже Линукс люблю!
Это не то
no subject
no subject
no subject
LANG=C?
Вобще странно, вроде терминал всегда отображал все символы которые мог отобразить, и кодировка в меню была нужна чтоб он шрифт правильно выбрал. Но если установить - MultiLanguage или что там, то он все символы нормально показывает.
Вобще, как то часто Вы в исходиники смотрите, всемирный разум давно такие проблемы порешал.
no subject
LANG=C?
Всем устраивает, кроме того, что не работает. Т.е. gnome-terminal не распознаёт после этого cp1251 как дифолтную локальную кодировку. Почему - не знаю, а разбираться не хочу, т.к. ненавижу локаль.
Вообще странно, вроде терминал всегда отображал все символы которые мог отобразить, и кодировка в меню была нужна чтоб он шрифт правильно выбрал.
Ну подумайте сами, предположим, у Вас есть файл в cp1251, и Вы его просто посмотреть хотите, т.е. more ему сделать. Кто-то же должен знать, что это файл в cp1251? Не надо же заставлять Вас специально фонты cp1251 для этого выставлять, а если файл в koi8-r - другие фонты? Поэтому и есть эта опция выбора кодировки, и очень удобная, кстати; к фонтам она вообще никакого отношения не имеет, а управляет перекодировкой входа и выхода.
В идеале, конечно, надо переходить полностью на utf-8, как кто-то уже написал. Тому же mutt'у я могу сказать set charset=utf-8, и выбрать эту кодировку в терминале. Но не все программы ещё хорошо это поддерживают.
Вобще, как то часто Вы в исходиники смотрите, всемирный разум давно такие проблемы порешал.
Я просто нетерпелив очень. Мне быстро надоедает читать длинную документацию, искать в сети, или какие-то запросы посылать в какие-нибудь форумы/рассылки... посмотреть в исходниках пусть не всегда быстрее, зато почти всегда интереснее.
no subject
cat file | iconv -f cp1251 -t koi8 - |less
или lynx --dump, в midnight commander тоже кнопка какая-то есть.
В mutt даже не знаю, ничего не трогал, само как-то заработало.
Вобще, мне кажется, Вы слишком много знаете и поэтому сильно необычный пользователь.
Совсем чайник - читал бы документацию,
Более-меннее опытный, знал бы что в gnome редко что работает если отойти от заложенной схемы хотя бы на шаг.
А совсем навороченный остался бы в Windows, поставил бы cygwin и получил бы всё то же но на меньшие деньги :))))))
no subject
Правильно:
LANG=ru_RU.CP1251
# сообщения по-английски:
LC_MESSAGES=C
# время "по-английски":
LC_TIME=C
Идеологически верно:
LANG=ru_RU.KOI8-R
# или, если позволяет используемое ПО, то LANG=ru_RU.UTF-8
# ну и далее
LC_MESSAGES=C
LC_TIME=C
no subject
no subject
(Anonymous) 2003-08-09 07:03 am (UTC)(link)no subject
no subject
no subject
У всех разный подход - Анатолию, в силу склада ума и опыта, проще залезть под капот и там паяльником чего надо... а некоторые могут и документацию прочитать, или вдруг ничего не иметь против русскоязыныч интерфейсов. Купили, например, ALT Linux себе, и счастливы.
Gentoo вообще не всякий решит себе ставить, равно как даже и Debian.
no subject
no subject
Потребительские минусы у любого чёрного ящика одинаковые - когда что-то всё-таки идёт не так как надо - а рано или поздно это всегда случается, оказываешься в зависимости от спецов. Которые могут оказаться среди друзей, а могут и не оказаться :)
Ну и понятно, если хочется чего-то из того, что не предоставлено завёрнутым на блюдечке, то приходится тоже как-то напрягаться. В этом смысле Альты как раз хороши, потому что у них механизм апдейтов взят из Дебиана, а их репозитарий пакетов обновляется каждый день. Если что - рраз - и проапгрейдился или что-то новое поставил прямо через сеть, и маяться не надо.
no subject
no subject
no subject
Просто надо понимать, что тут есть принципиальная разница в терминах. (лично для меня) с Windows основные проблемы состоят в том, что хотя большинство программ обладают красивыми инсталяшками и прочей необходимой цивилизацией, сама операционка иногда необъяснимым образом "портится" в разных аспектах своей жизнедеятельности. И вот тогда начинается шаманское разбирательство, которое иногда (не всегда, но часто) упирается в полное бессилие что-либо сделать. С Линуксом же получается наоборот - приложений меньше, они часто не завёрнуты в красивую обёртку и/или требуют больше возни при настройке. Но когда требуемая рабочая среда установлена и настроена, всё работает _железно_. В случае же проблем, если есть желание, можно дойти до самых корней и, гордясь достижениями человеческого разума (и собственного), починить.
no subject
Что же касается десктопа - то тут говорить о Линуксе еще рано. Если человеку важна совместимость с майкрософтовскими форматами, которые на данный момент являются де-факто стандартом, ему придется выбрать винды. Я намеренно не влезаю в сравнение Microsoft Office со, скажем, Star Office, потому что это beyond the point.
no subject
no subject
no subject
no subject
no subject
no subject
VmWare?
Re: VmWare?
Я пробовал все варианты - самый удобный выходит отдельный компьютер все-таки (или даже два, если драйверы писать)
no subject
no subject
Пожалуйста, если хотите чтобы я прочитал, пишите или по русски, или по английски, а не этой галиматьей.
no subject
У меня на домашней машине стоит программулька, позволяющая (правда, RO) просматривать разделы в ext3, а равно и ext2.
no subject
no subject
no subject
no subject
Собственно, ALT Linux, насколько мне известно, есть обработанный еще одним напильником RedHat -- но вот мне невдомек, нахрена козе баян (в смысле, еще одна обработка напильником).
Почему-то мне никогда не приходилось сталкиваться ни с какими проблемами локализации. Я, знаете ли, адепт Юникода. Мне эта лабудень типа cp1251 уже и так поднадоела -- зачем же восьмибитные кодировки еще и в Линукс тащить?
no subject
no subject
no subject
no subject
(у меня руки не дорходят кое что обратно в дебиан спортировать)
no subject
no subject
(Anonymous) 2003-08-09 03:32 pm (UTC)(link)Что ж делать-то, а? Иногда совсем непонятно, кто кому отвечает.
no subject
а где этому гному сказать, чтобы $HOME/scripts в $PATH добавил?
PАТH=$PATH;bin/bash;usr/home...
и т.д.
у меня работает.
Re: а где этому гному сказать, чтобы $HOME/scripts в $PATH добавил
Но, скорее всего, меня заглючило.
Спасибо, попробую.
no subject
(Anonymous) 2003-08-09 03:22 pm (UTC)(link)Не конфигурация Линукс, поразумней, конечно, но что-нибудь не слишком накрученное. С Вашим даром неунывающей занудности пойдет на ура. Те или иные протоколы или библиотеки, как набор современного джентельмена в сети.
Подумайте.
no subject
no subject
(Anonymous) 2003-08-09 08:58 pm (UTC)(link)ну не кнут, так не кнут