lqp - Юникод
[Recent Entries][Archive][Friends][User Info]
04:00 am
[Link] |
Юникод сделал “apt-get upgrade” - и mc перестал показывать русские тексты. Вместо них - кракозябры, какие получаются при попытке интерпроетировать koi8 - текста как iso8859-1 cпоследующим отображением его на US-ASCII. Сделал “apt-get source mc”, почитал Changelog, удалил из debian/patches/ файлик под названием 48_utf8-slang2.patch . После компиляции все стало тип-топ.
Что же отсюда следует? Отсюда следует еще одно подтверждение старой эвристики - корректная работа с текстами в разных кодировках и юникод - вещи, как правило, взаимоисключающие. Нет, теоретически возможно написать программу с юникодом и при этом работающую. На практики это означает написать вчетверо больше кода (для юникода, для юникода, для всех нормальных кодировок, и для конверсии между ними), на что идут только отпетые маньяки. А для произведений менее самоотверженных авторов - программа либо в юникоде, либо работает.
Tags: unicode
|
|
|
Извини, но mc сложно отнести к нормальным программам, поэтому я бы не стал по нему о чём-либо судить.
(Это при том что я сам его использую - но только из-за отсутствия альтернативы).
>из-за отсутствия альтернативы bash? ;)
Впрочем, mc умеет красиво работать с ftp и прочими vfs, не отнять.
Когда я не помню файлы хотя бы наполовину наизусть - работать со списком мне проще.
From: | lqp |
Date: | May 13th, 2006 - 02:04 pm |
---|
| | | (Link) |
|
Уй, это Вы мне bashем предлагаете читать FictionBook-и?
From: | lqp |
Date: | May 13th, 2006 - 01:50 pm |
---|
| | | (Link) |
|
И кто же это Вам сказал? Уж не Вагнер ли? Вы Вагнера меньше слушайте, он плохому научит. У него Мотифффф - "нормальная программа".
А mc - программа как программа, не хуже многих других.
Чтобы понять, что для простого клона коммандера у mc сильно слишком много глюков и зависимостей, Вагнер мне не нужен.
From: | lqp |
Date: | May 13th, 2006 - 10:06 pm |
---|
| | (разглядывая вывод apt-cache show) | (Link) |
|
И сколько же, по твоему, у него зависимостей?
И, кстати, клон-коммандера он не простой (это deco у нас простой), а весьма навороченный. Не говоря уже о том, что речь в данном случае идет не об его файлменеджере, а об его вьювере.
From: | ramendik |
Date: | May 13th, 2006 - 11:07 pm |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
Лично мне его навороты только мешают. (Надо бы наконец-таки попробовать водрузить deco; уже не помню, на чём я обломался в прошлый раз). Кстати, разве не правда, что он тянет за собой гном?
Что касается вьювера, в идеальной с моей точки зрения конструкции вьювер должен быть или _сверх_простым, или внешним.
Да, я до сих пор тоскую по Volkov Commander... Хотя в винде меня вполне устраивает Far. В нём почему-то глюков куда меньше, чем в mc.
From: | lqp |
Date: | May 13th, 2006 - 11:23 pm |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
mc и gmc уже довольно давно разные программы. Причем последний, кажется, забросили.
Внешний вьювер как абстрактная концепция это может и хорошо. Ну тут ситуация ровна та же, что и с микроядром :-) - это значит, что сколь-нибудь сложное взаимодействие вьювера с оболочкой будет делаться долго и неэффективно.
Насколько я знаю, в той части функциональности mc, что совпадает с функциональностью Far - глюков у него ровно столько же.
From: | ramendik |
Date: | May 14th, 2006 - 01:25 am |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
Только почему-то far у меня при таймауте ftp, например, молча подымается и продолжает, а mc кидается мессагами до упора. Это то, что вспомнилось с места именно из аналогичной функциональности.
да и работающий через раз ctrl-O я в Far как-то не встречал...
Если честно, функциональность mc, _превосходящая_ far, мне неизвестна. Впрочем, вряд ли и нужна. Даже отсутствие в mc ряда функций far, наппример показа списков файлов в архивах без распаковки, я бы ему спокойно простил. А вот подводные камни в неожиданных местах не радуют.
From: | lqp |
Date: | May 14th, 2006 - 07:40 am |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
при таймауте ftp
А, ftp. Ftp- это да. Ftp там какашка. Кстати, Ctrl-C помогает в таких случаях.
функциональность mc, _превосходящая_ far, мне неизвестна.
mc обширно и разнообразно скриптуем и конфигурируем. В отличии от. Уже одни виртуальные файловые системы чего стоят.
отсутствие в mc ряда функций far, наппример показа списков файлов в архивах без распаковки
?????
работающий через раз ctrl-O
Следует отметить, что случается это в случаях (подобных работе по telnet-у), при которых о работе Far-а речи вообще не идет. Так что это, строго говоря, другая функциональность.
From: | ramendik |
Date: | May 14th, 2006 - 12:23 pm |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
Ну, лично я предпочитаю скриптовать и конфигурировать не на уровне mc - чтобы и в нём, и в bash иметь одинаковые возможности.
Что до неработающего Ctrl-O, то он у меня лезет в обычном rxvt :(
![[User Picture]](http://lj.rossia.org/userpic/172165/60) | From: | kouzdra |
Date: | May 28th, 2006 - 09:34 pm |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
это значит, что сколь-нибудь сложное взаимодействие вьювера с оболочкой будет делаться долго и неэффективно.
Не значит это ничего - понятия об эффективности тут совсем другие. Из микроядра еще актуально максимум скорости выжимать, а из связки mc-viewer - ни на фиг не надо. Там запас на несколько порядков есть.
From: | lqp |
Date: | May 29th, 2006 - 07:40 am |
---|
| | Re: (разглядывая вывод apt-cache show) | (Link) |
|
Я имел в виду не столько скорость, сколько удобство и простоту. Нет в принципе всякие хинты вьюверу можно передавать и в командной строке, и через временные файлы но это умножение сущностей. В принципе ничего фатального, конечно, вопрос дизайнерского произвола. Ровно те же самые претензии, что к mc можно было предьявить Emacs-у
Скорость там, кстати, имеет значение. Когда файл открывается по нескольку секунд - это раздражает.
Как отпетый маньяк скажу -- мне остоиграло возиться с разными кодировками, потому внутри всех моих программ, подразумевающих использование не чистого ASCII, сидит юникод. А наружу перекодируется в то, что понимает клиент.
У меня, правда, специфика -- веб-приложения в основном. У них редко бывает кривой TERMCAP %))
From: | lqp |
Date: | May 13th, 2006 - 11:13 pm |
---|
| | | (Link) |
|
Дададад! Это классическая клиническая картина.
1) Человеку "остоиграет возиться с разными кодировками " и поэтому он выстраивает вместо системы с максимум одной перекодировкой (а при аккуратном проектировании часто можно обойтись и вообще без перекодировок, одним charset awareness, charset transparense или как это называется по научному) систему с минимум двумя.
2) При этом, поскольку ему стыдно признаться юзеру, что количество возни с кодировками только увеличилось, причем до абсурда, он не спрашивает кодировку у юзера напрямую, а пытается дедуцировать ее при помощи крови девственницы, собачей мочи, корня мандрагоры, локали, имени браузера, uname и прочих подручных средств. В половине случаев ошибается, естественно.
3) Когда его окончательно достают простодушные вопросы пользователей: "А почему у вас все НАСТОЛЬКО через жоппу?", он впадает в амок и обьявляет джихад всем неюникодным системам и программам.
А при чем здесь TERMCAP я и вообще не знаю. Кодировка символов в ней, по моим данным, нигде и никогда не хранится.
From: | (Anonymous) |
Date: | May 12th, 2006 - 10:33 pm |
---|
| | | (Link) |
|
Понимаю, разделяю. Решение, наверно просто - дерЖЖать mc установленный например под /usr - и модифицированный например mc1 или mcc как удобнее набирать - откомпилированный с поправками и поставленный под /usr/local
Могут смешивать environment друг друга, но с другой стороны если ваши preferences одинаковы, то у хрен с ним.
P.S. пользователю выше - у mc есть куча альтернатив, таких же клонов Коммандера. Поищите в центральном архиве свободных программ, www.freshmeat.net P.P.S. Кстати, дарю вам свою красивую раскраску для mc (вставьте для пробы файл ~/.mc/ini вместо раздела [Colors] и посмотрите что выйдет. Не забудьте сделать копию оригинала чтобы вернуться если не понравится)
[Colors] base_color=normal=black,default:selected=brightblue,lightgray:marked=brightred,lightgray:markselect=b rightred,yellow:errors=white,red:menu=black,lightgray:reverse=gray,lightgray:dnormal=black,lightgray: dfocus=brightred,lightgray:dhotnormal=blue,lightgray:dhotfocus=brightred,lightgray:viewunderline=brig htred,default:menuhot=brightred,lightgray:menusel=brightblue,lightgray:menuhotsel=gray,yellow:helpnor mal=black,lightgray:helpitalic=red,lightgray:helpbold=blue,lightgray:helplink=black,lightgray:helpsli nk=brightblue,yellow:gauge=black,yellow:input=black,yellow:directory=black,default:executable=red,def ault:link=blue,default:stalelink=brightmagenta,default:device=magenta,default:core=brightred,default: special=green,default:editnormal=black,white:editbold=gray,white:editmarked=black,yellow
From: | (Anonymous) |
Date: | May 12th, 2006 - 10:37 pm |
---|
| | | (Link) |
|
Да, чтобы выглядело красиво, надо чтобы терминалы ваши были либо светло-серыми светлее полоски-выбора, либо темнее - поставьте в properties запускающей иконки /usr/bin/xterm -bg "#f0f0f0" либо /usr/bin/xterm -bg "#d7d7d7"
Когда раскраска неуместна, запускайте MC как "mc -b" (black-white)
Делать на Debian то, что предлагается -- кощунство.
From: | (Anonymous) |
Date: | May 13th, 2006 - 02:59 am |
---|
| | | (Link) |
|
Да ну? Гораздо чище сделать правда так: откомпилировать 2 binaries - с юникодом и без него, точнее оставить один пакет как он поставлялся с distribution, второй сделать самому приложив латки. Поставить обе binaries с именами mc, mcc в /usr/bin (и добавить нужные support files). Вот и все.
Ваша сентенция странна - чем дебиан священен? - обычная, неряшливая linux distribution, каких много, причем с подбором далеко не лучших applications из-за какой-то кривизны взгляда, не исчерпывающегося особой строгостью к непротиворечию GNU-лицензиям. Я в начале 90х своими руками собирал нужные мне наборы applications под линуксом, не имею никакого пиетета к "distributions" за исключением их удобства для быстрой установки. Как правило все равно приходится выбирать что поставить руками и/или чистить installations от накиданного туда по дефолту ненужного мусора.
Начало девяностых разительно отличается от двухтысячных. В том числе, по качеству дистрибутивов и по понимаю того, что ручная сборка и раскладывание -- лучше способ получить unmaintainable помойку. Что вы будете делать с вашим самосборным mc, когда обновятся библиотеки?
Что же касается неряшливости и подборки приложений, то эту дискуссию мы оставим в стороне. Я принимал в них участие сотни раз и уже устал.
Вопрос - что ещё лучше, собрать в /usr/local или собрать кривой пакет. А сборка нужной версии есть не всегда...
Лучше собрать прямой пакет.
К сожалению, не каждый "десктоп-админ" тянет на правильного майнтейнера...
...а чтобы библиотеки не обновились, я как раз и сижу на sarge.
From: | (Anonymous) |
Date: | May 13th, 2006 - 11:43 pm |
---|
| | Под юниксом грубо говоря нет проблемы библиотек | (Link) |
|
Слава б+гу, под юниксом НЕТ проблемы библиотек в виде привычном для людей с мелким, мягким мышлением. Старые библиотеки имеют собственный номер версии и НЕ СМЕШИВАЮТСЯ с новыми. Установка новых в дополнение к старым решает проблему.
From: | ramendik |
Date: | May 13th, 2006 - 11:57 pm |
---|
| | Re: Под юниксом грубо говоря нет проблемы библиотек | (Link) |
|
Научите, пожалуйста - как мне поставить ещё один glibc? Ну свалился на меня 300-метровый бинарник с не тем glibc :(
| | Re: Под юниксом грубо говоря нет проблемы библиотек | (Link) |
|
на самом деле - можно, но это надо в бинарнике поковыряться :)
| | Re: Под юниксом грубо говоря нет проблемы библиотек | (Link) |
|
Ещё один glibc развернуть в отдельный каталог, использовать LD_LIBRARY_PATH, при необходимости непосредственно использовать динамический загрузчик от ещё одной glibc.
Это всё не фокус.
From: | lqp |
Date: | May 13th, 2006 - 01:48 pm |
---|
| | | (Link) |
|
Простите, и какую пробдему я должен решать столь странным способом? Юникодной локали у меня нет, и пока это физически возможно - не будет.
у mc "поддержка" уникода сделана на удивление через жопу. а что касается проблемы со свежей версией, я ее лечу apt-get install mc/stable :)
А я mc зачем-то на холд поставил, как будто знал! :-)
Да и практически можно написать программу, нормально работающую и с Unicode, и с различными кодировками. emacs, например. Да даже mozilla, уж на что кривая хрень. Но mc не работает ни в unicode, ни без.
From: | lqp |
Date: | May 13th, 2006 - 01:46 pm |
---|
| | | (Link) |
|
Уй, это emacs-то "нормально работает с кодировками"? Да он без большого бубна и многостраничного заклинания на елиспе вообще ни с какой кодировкой кроме US-ASCII не дружит. Хотя таки да - по стравнению с его внутренним представлением, юникод - сама простота.
И я сильно сомневаюсь, что мозилла правильно поймет юникод не в html-странице.
Не дружил. Три года назад. То, что сейчас в Debian stable (21.4), без заклинания не подхватывает только CP1251. А snapshot, кажется, и это уже умеет.
Остались, правда, некоторые проблемы с обменом данными через иксы. Но это у всех поголовно, кроме xterm. Через который и таскаем...
А у мозиллы как-то кроме html-страниц, и нету ничего... Хотя да, пару лет назад плагин, поднимающий внешний редактор, не умел туда-обратно передавать содержимое формы нормально. Сейчас - не знаю, смотреть надо...
From: | lqp |
Date: | May 13th, 2006 - 10:33 pm |
---|
| | | (Link) |
|
Я, собственно, имел в виду именно 21.[34]. Ранее, кстати, проблем было как раз меньше.
Проблемы, например, со шрифтами в иксах, с горячими клавишами, с гнусом.
А у меня нету проблем... Доктор, что я делаю не так? На 21.3 были, помню. С гнусом. Не то чтобы проблемы, но странное поведение. В 21.4 (гнус, впрочем, не из комплекта емакса, а из пакета gnus) починили.
Emacs 21j versii ehto voobshche ne Emacas, a govenaya podelka, sleplennaya neizbvestno kem i neizvestno zachem. Kanonicheskaya verisya ehto estestvenno 19.34, v kotoroj nikakikh problem ne bylo voobshche, ona byla 8-bit-clean i pro kodirovki nichego ne znala. V 20j versii nachalis' problemy, no eshche reshaemye. Zachem Stallman pozvolil mudakam delat' 21yu, dlya menya do sikh por zagadka. V lyubom sluchae, ona ne rabotaet. I rabotat' ne mozhet. Potomu chto mudaki.
Ага, заметно... Что мудаки - те, у кого почти все работает, а Д. Каледин, который не способен настроить свою систему так, чтобы писать кириллицей, он, конечно, маленькая хорошенькая феечка...
Оно, конечно, если с различными кодировками работать только внешними средствами, и в частности, почту читать ни в коем случае не емаксом, то может быть, 19-м и можно пользоваться. Но зачем создавать себе и другим лишние неудобства, если ты не китайский комсомолец, мой процессор понимать отказывается.
Если процессор не понимает, надо менять! +)
From: | lqp |
Date: | May 14th, 2006 - 07:10 am |
---|
| | | (Link) |
|
Так и у меня нету проблем. Все нужные заклинания отловлены на просторах интернета и аккуратно положены в .emacs .
Речь шла не о моих проблемах, а о проблемах емакса.
Так заклинания там, мягко говоря, не многостраничные. Одна строчка, включающая поддержку CP1251 и одна - рассказывающая ему, в каком формате отдавать выделение иксам.
Прошу прощения, у кого "у всех поголовно"? У меня как-то ни с openoffice.org, ни с konqueror, ни с firefox не возникало проблемы при обмене данными черех иксы ("средней кнопкой").
С firefox бывают. Не любит оно порой вставлять русский. Зависит от того, как закидывалось в буфер - видимо, не все режимы поддерживает вменяемо. То же самое в xterm вставляется нормально. С OOo не помню, то ли было, то ли глючит - я вообще этим ублюдком пользуюсь крайне редко. Конкверором не пользуюсь за патологической нелюбовью к KDE (оно сейчас идет по пути, который только что прошел emacs - неплохая операционная система, только вот вменяемый менеджер десктопа (и текстовый редактор, как водится) туда забыли положить - ну и массу других полезных инструментов заодно), так что ничего не могу сказать.
C firefox проблемы при перекидывании только из emacs или ещё откуда-то? Я бы попробовал реплицировать, если не только emacs.
Кажется, еще с кем-то были. Сейчас на testing не воспроизводится и с emacs
без заклинания не подхватывает только CP1251
заклинание: (codepage-setup 1251)
From: | lqp |
Date: | May 29th, 2006 - 07:07 pm |
---|
| | | (Link) |
|
И что оно делает?
После него, например, ispell-buffer заработает?
И что оно делает?
После него, например, ispell-buffer заработает?
Точно не знаю, но что-то такое, после чего в coding-system-alist появляется "cp1251", "cp1251-mac", "cp1251-dos", "cp1251-unix".
ispell-buffer работает.
Да, хуже емакса для кодировок просто нет. Проблема "копировать мышью из емакса в Мозиллу", например, в версиях от 20-й не решается в принципе (является официально зарегистрированным багом, на который все забили).
Такие дела Миша
![[User Picture]](http://lj.rossia.org/userpic/176603/5) | From: | yushi |
Date: | May 13th, 2006 - 01:31 pm |
---|
| | | (Link) |
|
Набежало снобов в комменты. =)
А я вот вас понимаю. Перестану использовать ALT Linux я, скорее всего, именно из-за того, что они зачем-то сломали в своём дистрибутиве поддержку восьмибитных кодировок в mcedit, как это не смешно. То есть не только из-за этого, но именно это стало типа последней каплей.
From: | (Anonymous) |
Date: | May 13th, 2006 - 11:46 pm |
---|
| | | (Link) |
|
Что мешает вам взять исходник какой вам удобно версии и откомпилировать его?
Это юникс, не windows, вы имеете доступ, компиляция проста до примитивности, в большинствен случаев это исполнение 3 ясно прописанных инструкций
![[User Picture]](http://lj.rossia.org/userpic/176603/5) | From: | yushi |
Date: | May 14th, 2006 - 09:03 am |
---|
| | | (Link) |
|
Я, естественно, так и сделал. Вот только возникает закономерный вопрос — нафига нужен дистрибутив, который после установки надо тщательно дорабатывать напильником? Система мне нужна для работы, а не для настройки.
Особенно если учесть, что в погоне за "дружественностью" современные линуксы полностью потеряли прозрачность внутреннего устройства. И то, что пять лет назад было построено по простым и ясным принципам, обросло таким количеством глючного и недокументированного барахла, что решение проблем с системой, как и в Windows, стало доступно только специалистам (пример — чудовищные сервисы автомонтирования). У меня нет времени на чтение мануалов, деньги мне платят не за это. В 2000 году это не было помехой использованию Linux. Сейчас — является.
![[User Picture]](http://lj.rossia.org/userpic/176603/5) | From: | yushi |
Date: | May 14th, 2006 - 09:07 am |
---|
| | | (Link) |
|
У меня нет времени на чтение мануалов
Я имел в виду — на чтение мануалов в тех объёмах, которых требует упромысление submount, юникода и прочих ужасов.
![[User Picture]](http://lj.rossia.org/userpic/12998/402) | From: | ujo |
Date: | May 28th, 2006 - 10:12 pm |
---|
| | | (Link) |
|
zsh тоже не работает с уникодом
Ещё можно почитать жонглирокание какашками в меёллистах haskell. Они там задеклариовали нативный уникод ещё в те времена, когда никто не знал что это такое. Ну и разумеется - все библиотеки ввода-вывода просто через жопу с локализацией работают. Причём это всё уже проштемпелёвано в стандарте и так просто не поменять.
| | Re: абсолютно согласен | (Link) |
|
zsh уже работает с юникодом. Чаще надо кэши обновлять.
баг всё-таки надо загнать дебианщикам.
From: | lqp |
Date: | May 14th, 2006 - 07:41 pm |
---|
| | | (Link) |
|
И хотел бы я знать- а как Вы собираетесь жить одновременно с тремя бабами языками ? Без юникода? И еще китайский поддерживать?
From: | lqp |
Date: | May 29th, 2006 - 08:16 pm |
---|
| | | (Link) |
|
А как бы я жил с тремя бабами языками и с юникодом? Вот точно так же, с тем отличием, что трахаться можно с бабами, а не с юникодом.
Это рекламное вранье, будто как-то нужен или особо полезен для жизни с бабами языками.
Для жизни с языками нужен, например, соответствующий шрифт. Вы может быть не в курсе, но но в мире не существует и не может существовать шрифтов, содержащих весь диапазон символов. И - не знаю как в венде, а в X11 не существует ни способа указать, какой диапазон символов поддерживает unicode-шрифт, ни способа указать, какой диапазон символов необходим для вывода данного текста. То есть мы в этом вопросе - слава юникоду - возвращаемся во времена самого древнего и примитивного шаманства.
Для жизни с бабами языками нужна, например, проверка орфографии...etc.
Для полноценной поддержки китайского языка необходима возможность вставить в текст лбой иероглиф. То есть вот буквально, любой - придумал, нарисовал, - и используешь. Существующие кодировки китайского это с грехом пополам, но позволяют. Юникод (в каком бы то ни было виде) - нет.
Для полноценной поддержки китайского языка необходима возможность вставить в текст лбой иероглиф. То есть вот буквально, любой - придумал, нарисовал, - и используешь. Существующие кодировки китайского это с грехом пополам, но позволяют. Юникод (в каком бы то ни было виде) - нет.
ирония судьбы: в GuoBiao 2312 (как впрочем и в Big5) нету матерных иероглифов 肏,屄,屌, а в юникоде есть :) Более того, современный стандарт GuoBiao 18030 является перекодировкой Unicode.
Кстати, существует нормативный список иероглифов, которые дозволяется использовать в газетах, и он меньше и старого GuoBiao, и китайской части Unicode. Так что на практике, например, разница между Unicode и GB2312 исчезающе мала, кроме того, что Unicode удобней. Разве что вам захочется читать древние буддистские тексты. Но там в любом случае будут редкие иероглифы, которых нет ни в одном стандарте, и своя какая-то специфическая кодировка.
From: | lqp |
Date: | May 30th, 2006 - 05:18 am |
---|
| | | (Link) |
|
Ну так о том и речь, что Юникод просто не допускает наличия каких-либо иных кодировок рядом с собой.
А, кстати, я перепутал, это только для японского есть нормативный список, для китайского похоже нет. Во всяком случае, я не нашёл про это ничего. Причём там у японцев даже не то чтобы запрещено использовать иероглифы, не входящие в список, но рекомендуется снабжать их транскрипцией.
Ладно, так или иначе все эти компьютерные стандарты содержат достаточно иероглифов для повседневных нужд, плюс-минус.
То есть вот буквально, любой - придумал, нарисовал, - и используешь. Существующие кодировки китайского это с грехом пополам, но позволяют.
Кстати, что именно тут имеется в виду?
From: | lqp |
Date: | May 31st, 2006 - 07:40 pm |
---|
| | | (Link) |
|
Слабая критика. Ничто не мешает вставить иероглифы, которые используются нацменьшинством Наси, в Юникод в очередной версии, в котором уже есть русский, греческий и гуджарати. Но греческий и гуджарати никогда не включат в китайский стандарт. И в юникоде не 2^16 codepoint-ов, а 17*2^16.
From: | (Anonymous) |
Date: | September 27th, 2006 - 10:49 am |
---|
| | | (Link) |
|
сегодня имел много секса с mc на redhat, вылечилось ./configure --with-screen=mcslang , таким образом нормально русский показывает. вот только как его отучить от автоустановки UTF8 локали при старте... |
|