>Дык за то и борется гном - чтобы 90% нужд "обычного пользователя" покрывать НЕ ВХОДЯ В КОНСОЛЬ.

Что-то мне это напоминает... Ах да, это то, что предлагала одна всем известная, не к ночи будь помянута, фирма. (все поняли, о чем я!!!).

Интересно, а что делать тем, у кого программа работает в консоли и нет X-ового варианта. Прямой пример, бухгалтерский комплекс IceB?! Кстати говоря, работает в koi8... Ах да... разработчики полные болваны, не предусмотрели такого гиганта мысли как gnome... с принудительным utf.

>про mc мы ведь не будем начинать флейм, правда?

А почему нет?!! У меня это - самый используемый файловый менеджер под иксами. А из-за проблем гнома у меня ..глюки..

>Почему маковских юзеров не всех несет в консоль "рано или поздно"?

Никогда не пользовал Мак... а что, там есть консоль?

>...авторам хошь-не хошь приходится выпрямлять кривизну...

А кто сказал, что у этих авторов - кривизна!!! Работало себе приложение, работало... хлопот не доставляло, а тут БАЦ! Пришел gnome, redhat и принудительный юникод и все... программа уже, оказывается, кривая!!! Это что, нормальный подход.

А вообще речь идет не о юникоде, а о том, что разработчики гнома, по каким-то своим причинам (возможно, по прямому указанию "сверху", политика, однако) не сделали механизм определения кодировки текущей ФС. Хотя фактически, алгоритм определения кодировки очень прост и достаточно легко реализуем, но... политика есть политика!!!

Блин, хоть в настройках бы дали возможность самому выбрать кодировку, но нет. НА ЛИНУКСЕ ДОЛЖЕН БЫТЬ ЮНИКОД. И ТОЧКА. -- Это нормально?!

> при условии того, что выполнить надо чуть больше, чем должно быть можно average user'у.

Во! Мы же говорим про среду, ориентированную именно на этого average user (того самого кофейника, о котором была первая реплика - и который до чтения доков не снисходит). А тот, кто не average - откроет консоль - и дальше пусть читает мануалы...

> minicom, cda, BitchX, mutt

Я же написал - ДЛЯ МЕНЯ ЛИЧНО. Не пользую ничего из этого, кроме minicom (раз в 100 лет и точно без необходимости пользовать что-то, кроме ASCII). Стричь под одну гребенку не призываю - призываю как минимум разделять интересы average users & power users.

> если бы!

А что не так? Смотрим http://www.freedesktop.org/Software/BadSoftware. Патчики появляются потихоньку... Силами того же РХ, например.

>Интересно, а что делать тем, у кого программа работает в консоли и нет X-ового варианта. Прямой пример, бухгалтерский комплекс IceB?! Кстати говоря, работает в koi8... Ах да... разработчики полные болваны, не предусмотрели такого гиганта мысли как gnome... с принудительным utf.

В 21 веке не предусматривать unicode действительно надо быть болваном. Ибо есть такие вещи как глобализация экономики, которую кстати комьютеры и интернет подстегнули некисло.

>А почему нет?!! У меня это - самый используемый файловый менеджер под иксами. А из-за проблем гнома у меня ..глюки..

У гнома нет проблем, они скорее у тебя, выставь переменную окружения и не парься. В чем проблема?

>Никогда не пользовал Мак... а что, там есть консоль?

Для тех кто в танке - MacOS X основана на ядре Darwin, произростающем из BSD. И консоль там есть и много чего другого

>А кто сказал, что у этих авторов - кривизна!!! Работало себе приложение, работало... хлопот не доставляло, а тут БАЦ! Пришел gnome, redhat и принудительный юникод и все... программа уже, оказывается, кривая!!! Это что, нормальный подход.

Если программа не отвечает современным требованиям, она действительно становится кривой. Никто же не жалуется на то что Norton Commander в Вындовс длинные имена не показывает, и не орёт "пришел Microsoft и Вындовсъ и у меня NC глючит!"

>А вообще речь идет не о юникоде,

О нём родимом и идет

>а о том, что разработчики гнома, по каким-то своим причинам (возможно, по прямому указанию "сверху", политика, однако) не сделали механизм определения кодировки текущей ФС.

У ФС нет кодировки, есть кодировка у файлов, она ни в каких конфигах не прописана, так что надо принимать какую-либо дефолтную. Отсюда вопрос - какая будет она по дефолту в самых распространенных дистрах? Правильно, UTF-8, поэтому геморрой надо переложить на меньшее количество юзеров. С точки зрения разработчиков все верно.

>Хотя фактически, алгоритм определения кодировки очень прост и достаточно легко реализуем, но... политика есть политика!!!

Ага, а если имя файла из 3-х букв по-русски, думаю тут к file-селектору словарик надо прикрутить на многие мегабайты. Лол.

>Блин, хоть в настройках бы дали возможность самому выбрать кодировку, но нет.

чем собственно плохая настройка .bashrc?

>НА ЛИНУКСЕ ДОЛЖЕН БЫТЬ ЮНИКОД. И ТОЧКА. -- Это нормально?!

Нет, тебе дается выбор - трахаться и менять все обратно на KOI8-R или юзать UTF-8. Только mainstream Уже на UTF-8, а как известно все кто не в mainstream имеют наибольший геморрой. Вот и все.

> Если честно - я не знаю ни одной полезной консольной утилиты на ncurses.

MsgED =)

Кто помнит еще, что это? ;)

>У ФС нет кодировки, есть кодировка у файлов

Что значит у ФС нет кодировки! А как по вашему запоминаются имена файлов? В самом файле, что ли?!!!

>Ага, а если имя файла из 3-х букв по-русски, думаю тут к file-селектору словарик надо прикрутить на многие мегабайты. Лол.

Ну зачем мыслить так плоско?!! Простой пример: 1. Получаем текущую кодировку ( locale :-) 2. В зависимости от полученного результата устанавливаем глобальную переменную с кодировкой ФС для диска, на который идет запись. 3. В особо тяжких случаях можно пропарсить в /etc/fstab (/proc/mounts ... ), на предмет получения параметров монтирования конкретного устройства.

Все это - один раз за сеанс.

Это так... навскидку. Возможно есть более правильные пути.

Много хлопот это не прибавит и в быстродействии не отнимет, зато точно ничего не попортится. По крайней мере, файлы пользователя будут иметь правильные имена в зависимости от особенностей конкретного применения, а не "общего пути развития среды". Кстати, получается, что графическая среда диктует свои условия пользователю, а должно быть наоборот. Так теряется одно из преимуществ UnixWay'я - возможность одну и ту-же задачу решать разными путями.

>чем собственно плохая настройка .bashrc?

Да меня .bashrc устраивает. Кстати, я использую ./bash_profile. Кроме того, каким, спрашивается боком касается .bashrc запуска среды gnome?!! Может у меня zsh? Или вообще id:4:initdefault:

>Нет, тебе дается выбор - трахаться и менять все обратно на KOI8-R или юзать UTF-8.

Ничего себе выбор!!! А кто вообще дал право разработчикам гнома ставить мне такой выбор (я имею ввиду выбор кодировки ВСЕЙ системы)!!! Лучше я слезу с гнома и буду использовать KDE, который, кстати, таких ультиматумов не предъявляет и работает с koi8-* превосходно, безо всяких глюков... Ах да, это же не глюк, это фича!!!

Хотя, конечно, обидно. Интерфейс гнома мне больше нравится, но работать с ним (именно работать а не экспериментировать) достаточно опасно. Откуда я знаю, может еще где-нибудь возникнет подобная нестыковка с моей системой? Или очередное изменение политики? Что тогда? Прощай данные?

> ./bash_profile

Сорри, описка, читать как ~/.bash_profile

Хмм =)

Тех кто пользуется мэйнстримом видимо намного больше, а остальные ленивы для того чтобы предложить соответствующий патч =) UTF-8 без вариантов будущее, кто не хочет ехать в паравозе, может вместе с KOI8-R попробовать поспеть за прогрессом на дрезине :)

Может быть за UTF и будущее, я не спорю. Но я хочу нормально работать в настоящем!!!

И я вполне нормально могу делать это и без гнома, и я РЕАЛЬНО РАБОТАЮ БЕЗ гнома. Но я хотел бы перейти на гном. Но пока не могу - ненадежность решений меня настораживает.

А вообще, еще раз повторяю, РЕЧЬ НЕ О UTF!!! Я ничего не имею против этой кодировки. Я говорю о ПРИНУДИТЕЛЬНОМ НАВЯЗЫВАНИИ ЭТОЙ КОДИРОВКИ!!! Причем навязывании прозрачном. Потому, что все знают, что гном (точнее gtk-2) использует внутреннее представление строк в формате unicode. Но о том, что гном тупо и нахально игнорирует кодировку текущей пользовательской среды я узнал только сегодня. Раньше я все списывал на баги гнома.

И я еще раз повторяю: на мой взгляд, игнорирование пользовательской среды одним приложением, которое хоть и является "последней инстанцией" во взаимодействии пользователя и компьютера, но все же работает не само по себе, а используя ресурсы и настройки пользовательско среды в целом ( ядро, различные демоны, иксы, другие среды, т.п. ) - это неправильно!!!!!!!! Тем более, если учесть, что игнорирование кодировки для не-utf'ных локалей приведет к полной нечитаемости имен файлов в других средах, даже тех, которые используют юникод, но имеют средства для определения текущей локали, то можно сказать об очень большой недоработке этого приложения.

под UTF8 нехило глючат: centericq, slrn, links, elinks, mc, mp3blaster ...
Это только из того что я проверял. Как только с юникодом будут нормально работать все программы я на него вернусь, а пока koi8-r

> Получаем текущую кодировку ( locale :-)

Извините - конкретно какую? LANG? LC_xxx? А если на машине работают разные пользователи - немец и индус - и у каждого свой набор в установок локализации bashrc? Вы получите диск, который нельзя корректно прочитать НИ В ОДНОЙ КОДОРОВКЕ??? (выбор файлов при выборочном restore доставит массу наслаждений администратору). А если у вас диск сетевой (smbfs) - Вы тоже эту эвристику будете применять - не глядя на то, с какими опциями кодировок он подмонтирован? Вы так далеко уйдете...

Извините, но такая smart-овость софта чревата неприятностями. Все, что Вас попросили в этом треде - это поставить одну переменную окружения, специально для гнома - чтобы не интерферировать с остальными настройками пользователя. Вы почему-то сочли это личным оскорблением

> Ничего себе выбор!!! А кто вообще дал право разработчикам гнома ставить мне такой выбор (я имею ввиду выбор кодировки ВСЕЙ системы)!!! Лучше я слезу с гнома и буду использовать KDE, который, кстати, таких ультиматумов не предъявляет и работает с koi8-* превосходно, безо всяких глюков... Ах да, это же не глюк, это фича!!!

Да никто перед вами лично его не ставит (гном вообще не любит, когда у пользователя есть выбор - особенно если выбор тяжел:) Либо вы берете то, что вам дает дистростроитель - тогда либо оно работает, либо вы ругаете дистростроителя за то, что при выборе koi8 он не ставит переменную среды. Либо вы сами устанавливаете себе гном - тогда потрудитесь почитать доки, плиз и установить переменную (считайте это частью процедуры инсталляции, пункт 101b - If you want to save 8-bit filenames ...).

ЗЫ Я в курсе, что бывают проблемы даже с этой переменной. Но это явные баги, их репортят и по возможности фиксят. Я сам однажды, давно, получил по шапке, когда поломал русификацию своей проги в 8-битных локалях - ничего, починил...

ЗЗЫ А кто может рассказать - каким образом KDE определяет кодировку файлов на диске?

>Извините - конкретно какую? LANG? LC_xxx? А если на машине работают разные пользователи - немец и индус - и у каждого свой набор в установок локализации bashrc?

А они что, все работают от имени одного пользователя? Или что, сессии одного используют данные из сессии другого? Вы все смешали в кучу!!!

Кроме того, речь не о том, что у одного так а у другого по другому. Речь о том, чтобы у одного пользователя все файлы в ФС имели имена в одной и той-же кодировке!!!

А значение локали, думаю, следует брать ил LC_MESSAGES - так будет правильнее.

>А если у вас диск сетевой (smbfs) - Вы тоже эту эвристику будете применять - не глядя на то, с какими опциями кодировок он подмонтирован? Вы так далеко уйдете...

Вы внимательно читали мое предыдущее сообщение? Посмотрите еще раз по поводу /proc/mounts.

>Вы почему-то сочли это личным оскорблением

Да причем здесь личное оскорбление!

За подсказку по поводу переменной/ых окружения огромное спасибо!!! Вот только пригодится ли... Ведь в следующем релизе может быть еще какая-нибудь фича... Которая у меня (и не только у меня) боком вылезет.

> Речь о том, чтобы у одного пользователя все файлы в ФС имели имена в одной и той-же кодировке!!!

Это у Вас. А у меня речь о том, что на одной партиции /home (используемой _разными_ пользователями) у вас получится каша из кодировок в именах файлах. И я пожелал удачи админу такого сервера при селективном restore. И терпения, много терпения. Единственный выход - насильственное насаждение уникода в именах файлах. Еще на этапе инсталляции ОС.

> Ведь в следующем релизе может быть еще какая-нибудь фича... Которая у меня (и не только у меня) боком вылезет.

Это вообще универсальное заклинание против обновления софта. В каждом новом релизе может быть новая фича...:)

ЗЫ Сорри, про параметры монтирования проглядел.

> навскидку: minicom, cda, BitchX, mutt. да и bash

да ладно вам - mutt понимает юникод, bash - возможно, единственная оболочка, которая нормально рабоатает с юникодом. тот же zsh глючит

> А почему нет?!! У меня это - самый используемый файловый менеджер под иксами

для мц есть патчи - всё работает.

> НА ЛИНУКСЕ ДОЛЖЕН БЫТЬ ЮНИКОД. И ТОЧКА. -- Это нормально?!

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

>А значение локали, думаю, следует брать ил LC_MESSAGES - так будет правильнее.

Нет. Правильно будет брать из LC_TELEPHONE. :-)

LC_CTYPE, помнится, за буковки отвечает. Хотя все равно я за юникод.

> под UTF8 нехило глючат: centericq, slrn, links, elinks, mc, mp3blaster ..

лол... елинкс имеет отличную поддержку юникода (смотри ./configure --help, мц имеет патчи. с остальным согласен

Интересно, где эти патчи. Если Вы про redhat овскую сборку, то у них пока даже mcedit не работает.

Не совсем в тему, что за иконке на самом первом http://ftp.gnome.org/pub/GNOME/teams/marketing/en/2004/two-eight-screenshots/... скриншоте гнома 2.8?

>У меня в mc редактор - vim. там нет проблем.

Мы говорим про обычных пользователей - им даже mc-шный редактор сложен, не то что vim.

>НА ЛИНУКСЕ ДОЛЖЕН БЫТЬ ЮНИКОД. И ТОЧКА. -- Это нормально?!

Да. Более того, весь KDE внутри юникодный (другой момент, что переключение в koi8-r не несет никаких трудностей), вся винда внутри юникодная. И доки для ООо и MS Office внутри юникодные (тяжелый 97 и ниже не считаем). Дофига чего юникодного, короче говоря.

И это правильно - нафига китайцев мучать или 4 локали русских иметь?

>Ничего себе выбор!!! А кто вообще дал право разработчикам гнома ставить мне такой выбор (я имею ввиду выбор кодировки ВСЕЙ системы)!!!

Они разработчики и никому ничего не должны, поэтому данное право у них есть по-умолчанию. Другой момент, что сделали они малость кривовато.

>LANG? LC_xxx? А если на машине работают разные пользователи - немец и индус - и у каждого свой набор в установок локализации bashrc?

>Вы получите диск, который нельзя корректно прочитать НИ В ОДНОЙ КОДОРОВКЕ???

Это на задворках Китая в условиях дикой нехватки машин? Значит будут использовать fs, которая либо жестко хранит все названия в utf, либо работать только в своей домашней папке.

>ЗЗЫ А кто может рассказать - каким образом KDE определяет кодировку файлов на диске?

Есть мысль, что никаким. Потому как была у меня локаль utf, сохранил я пару файликов на ext3 с русскими названиями, а потом переделал кодировку на кои и названия побились. Пришлось перемонтировать все назад и быстренько их переименовывать, пока не началось.

Что есть неудобно (однако должно реализовываться все же на уровне fs).

> Это на задворках Китая в условиях дикой нехватки машин? Значит будут использовать fs, которая либо жестко хранит все названия в utf, либо работать только в своей домашней папке.

А что - многопользовательские системы только в Китае используются?:) Сама fs это полбеды - нужен еще уровень vfs, который понимал бы кодировку входящих имен, типа сисколла create( const char* name, const char* encoding - и дальше уже разбирался, перекодировать это дело в уникод или оставлять как есть (возможно, на уровне конкретной fs). Другого универсального способа я не вижу...

> Есть мысль, что никаким.

Т.е. внутреннее представление строк в KDE - не уникод, как в гноме? Жаль...

> Другого универсального способа я не вижу...

Ну, или на уровне ОС просто объявить валидными только уникодные строки. Все сисколлы ожидают на входе только уникод.

> Ну, или на уровне ОС просто объявить валидными только уникодные строки. Все сисколлы ожидают на входе только уникод.

И наступит щастье для эмигрантов, переводчиков и полиглотов. А всем остальным 99% юзеров оно нафига? Если типичный российский юзер знает только один язык (русский), то зачем ему возможность видеть одновременно с русским еще и китайский? Все равно он прочитать не сможет. То есть выгод от utf8 никаких нет, зато есть геморрой. Мало того, что utf8 сложнее обрабатывать, потому что оно уже не есть char[], так еще и для русского используется 2 байта вместо 1 -- на тонком канале, где и так все медленно работает, еще скорость в 2 раза упадет.

Я так смотрю к кнопке ОК справа уже все привыкли, теперь новую беду нашли - UTF...

> при условии того, что выполнить надо чуть больше, чем должно быть можно average user'у.

>Во! Мы же говорим про среду, ориентированную именно на этого average user (того самого кофейника, о котором была первая реплика - и который до чтения доков не снисходит). А тот, кто не average - откроет консоль - и дальше пусть читает мануалы...

хе. во-первых, покажите мне маны в MacOS X. например, на ейный (макосовский) сетевой автомаунтер. вы же сами о ней (MacOS) заговорили -- а я поддержал. так как видел ее не только на картинках и имею на нее большой зуб.

далее. прекратите, наконец, путать понятия ``консоль'' и ``терминал''. это разные вещи! особенно, когда в роли последнего выступает эмулятор терминала.

---vk

yesss!:)))

Не, все не так. По четным числам ненавидим кнопки, по нечетным - UTF. По выходным - XML. Вроде, все?

> хе. во-первых, покажите мне маны в MacOS X. например, на ейный (макосовский) сетевой автомаунтер. вы же сами о ней (MacOS) заговорили -- а я поддержал. так как видел ее не только на картинках и имею на нее большой зуб.

Дык кто же сказал, что мы должны повторять ошибки Маковцев? МакОС - не икона, а коллекция множества удачных решений. И набор проблем тоже (вытекающих, в частности, из проприетарности). Решения бум переосмысливать. Проблемы бум стараться не повторять. С макосом я действительно не "работал" в полном смысле - я просто несколько раз пробегался по интерфейсу до нужных мне кусков и изучал, как оно там было. И как раз для average user там все достаточно логично (хотя к логике после винюков надо немножечко привыкнуть).

> далее. прекратите, наконец, путать понятия ``консоль'' и ``терминал''. это разные вещи!

Спасибо, я в курсе:) Но в данном контексте разница не особо велика. С уникодом проблемы есть и там и там - разве что в терминале чуть поменьше - что, однако, не мешало minicom сходить с ума в обоих случаях (до тех пор, пока я не убил файл локализации).

>Т.е. внутреннее представление строк в KDE - не уникод, как в гноме? Жаль...

Вообще я там выше писал, что юникод. Это если ты не заметил. Другой момент, что на ext3 он пишет имена файлов в кодировке локали, т.е. он ничего не переделывает (и не должен).

А вот в ext3 ключик codepage не помешал бы.

>А что - многопользовательские системы только в Китае используются?:)

Я бы хотел посмотреть, как в корпоративной сетке немец ни с того ни с сего стал свои рабочие файлы называть по-немецки, когда вокруг русские, знающие только английский язык.

>Я так смотрю к кнопке ОК справа уже все привыкли, теперь новую беду нашли - UTF...

Насколько я помню, ты можешь поменять под себя интерфейс - т.е. кнопку вернуть налево.

Понятного интерфейса не существует.

Я тут учил свою маму как позвонить в МТС-совскую АССА и сделать себе пароль. После чего надо было врубить ИССА.

Я пятнадцать минут просто уговаривал ее позвонить и сделать так, как ей скажет оператор.

Среднего юзера тоже не существует - есть неучи и есть опытные. Так называемые "средние" - это люди, способные понять, что у них выключен монитор и умеющие работать с определенным набором прог (и возможно поставить корявенько винды).

>Т.е. внутреннее представление строк в KDE - не уникод, как в гноме? Жаль...

QString - уникод, есть спец классы для работы с уникодом, как то QTextCodec и прочее

> То есть выгод от utf8 никаких нет, зато есть геморрой.

Слушайте, я Вашей сердечности прямо завидую. Вы тааак беспокоитесь о благополучии и здоровье простых российских юзерах... Может, они Вам просто кучу бабок должны? :)

Я лично себя полиглотом (и тем паче эмигрантом) не считаю (всего-то -- два иностранных свободно и ещё один иностранный со словарём), но вот повсеместный переход на юникод всячески одобряю. Знаете почему?

Потому что я как простой российский юзер (кстати, спасибо Вам за заботу обо мне :)), слушаю музыку. И смотреть на убожество вместо умлаутов и диакритических символов при определении состава CD через CDDB не хочу -- хоть убейте. И когда я буду узнанные диски перегонять в Ogg Vorbis, я хочу, чтобы названия песен в именах файлов не корёжились. Просто потому, что я уважаю другие языки и другую культуру.

То, что пропагандируете Вы, по факту, -- неуважение к другим языкам и выставление своей культуры над другой. Что слишком часто порождает ксенофобию и прочую мерзость.

Может, не стоит поощрять неграмотность и наплевательство на чужую культуру?

> для мц есть патчи - всё работает.

Вот кстати. Пытался я его с этими патчами собрать... не хочет. Есть у кого подробная инструкция о том, какую версию брать, и в каком порядке что накладывать?

> Другой момент, что на ext3 он пишет имена файлов в кодировке локали, т.е. он ничего не переделывает (и не должен).

Чего-то я не понимаю. Если я в GUI (диалог file save as) задаю имя - оно из диалога в какой кодировке возвращается? Если потом я его, допустим, в какой-то label вывожу - оно в какой кодировке? И если я потом делаю fopen () - параметр в какой кодировке идет?

> А вот в ext3 ключик codepage не помешал бы.

Да. А пока его нет - единственный выход гарантировать себя от проблем с кодировками - хранить имена файлов в уникоде.

> Я бы хотел посмотреть, как в корпоративной сетке

А в университетской? Там ведь каждый студент волен называть файлы как угодно (кстати, про языки и студетнов - никогда не забуду функцию driveNogiKolobka у одного из моих одногруппников:) - главное, чтобы результат дошел с именем, приемлемым для препода.

Угу. Ну, Вас послушать - так вообще маркетологи от софтвер-бизнеса даром хлеб едят...:) А они его не даром едят - они ведь МС вырастили, именно на некоем представлении о понятном и среднем...

>А в университетской?

По стандартам университета. Если ему вообще кто-то куда-то что-то даст сохранять.
У нас по жизни давали логин и папочку. Одну. На все. Выход только из тех залов, куда есть допуск и только в определенное время и дни. Никаких проблем.

>оно из диалога в какой кодировке возвращается?

Если внутри приложений КДЕ, то в юникоде, естественно. А вот если ты этот файлик начнешь сохранять, а локаль у тебя koi8-r, то и у файлика имя сохранится в этой чудной локали.

>И если я потом делаю fopen () - параметр в какой кодировке идет?

Хрен его знает.

>А они его не даром едят - они ведь МС вырастили, именно на некоем представлении о понятном и среднем...

Админом в конторе из одних девушек не желаешь пару месяцев поработать? Ты сразу убедишься, что маркетологи ошибаются (даже картинки и подсказки не помогают - жуть).

> Потому как была у меня локаль utf, сохранил я пару файликов на
> ext3 с русскими названиями, а потом переделал кодировку на кои
> и названия побились. Пришлось перемонтировать все назад и
> быстренько их переименовывать, пока не началось

А зачем перемонтировать-то было? for i in *; do { n=`echo "$i" | iconv -f utf8 -t koi8-r | tr -d "\n"`; mv "$i" "$n"; } done

Не далее как сегодня делал - только я наоборот, с KOI8-R на UTF-8 переключался :-)

>Если внутри приложений КДЕ, то в юникоде, естественно. А вот если ты этот файлик начнешь сохранять, а локаль у тебя koi8-r, то и у файлика имя сохранится в этой чудной локали.

ВОТ!!! Именно так и поступает правильно написанное приложение, не считающее себя пупом земли... вернее системы!!!

И именно так НЕ ПОСТУПАЕТ этот самый gnome... Или в 2.8. пофиксили (в смысле, сделали по-человечески )?

дык на словах elinks имеет отличную поддержку юникода, да только как только я его там врубил у меня с менюхами начал какой-то кошмар твориться,- всё разъезжается, прямо страшно смотреть... elinks 0.9.2rc4 ncurses 5.4

(а ещё с юникодом глючит mikmod)

В доках к slrn написано что нормальная поддержка юникода там будет только с выходом slang-2.0, вот... так что я на utf-8 нескоро...

>> для мц есть патчи - всё работает.

>Вот кстати. Пытался я его с этими патчами собрать... не хочет. Есть у >кого подробная инструкция о том, какую версию брать, и в каком порядке >что накладывать?

>int19h *** (*) (17.09.2004 2:46:04)

Вот кусочек и гентушного ebuild'a, которым добрый человек на gentoo-форуме (linuxshop.ru) поделился: ------------------------------------------------------------------ if use unicode; then epatch ${FILESDIR}/${P}-utf8.patch epatch ${FILESDIR}/${P}-utf8-input.patch epatch ${FILESDIR}/${P}-utf8-fix.patch epatch ${FILESDIR}/${P}-utf8-hints.patch fi for i in security-fixes asmsyntax X-error file getpwuid key.c slang-crash slang tempfile; do epatch ${FILESDIR}/${P}-${i}.patch done;

epatch ${FILESDIR}/${P}-largefile.diff epatch ${FILESDIR}/${P}-x11browser.diff -----------------------------------------------------------------

у меня собралось и работает без проблем. правда раньше я без slang обходился, но ради такого дела пришлось собрать и его...

Если девушки симпатичные, а я был бы холостым - да, конечно:) А так - нет, спасибо:)

оййёёёёпрст... %-/
извините за такого вида пост, я тут еще не освоился, потому и анонимус пока ;-)

if use unicode; then
    epatch ${FILESDIR}/${P}-utf8.patch
    epatch ${FILESDIR}/${P}-utf8-input.patch
    epatch ${FILESDIR}/${P}-utf8-fix.patch
    epatch ${FILESDIR}/${P}-utf8-hints.patch
fi
for i in security-fixes asmsyntax X-error file getpwuid key.c slang-crash slang tempfile; do
    epatch ${FILESDIR}/${P}-${i}.patch
done;

> ВОТ!!! Именно так и поступает правильно написанное приложение, не считающее себя пупом земли... вернее системы!!!

А может, Вы знаете, какую строку передают в fopen? И как она из уникодного QString становится "локальной"?

> Или в 2.8. пофиксили (в смысле, сделали по-человечески )?

Вряд ли в 2.8 что-то изменилось. Внутри гном был и есть уникодный. И для конверсии имен файлов приложение должно не забыть вызывать соотв. функцию (если не делает этого - это бага). И эта функция анализирует ту самую переменную, насколько я знаю - без всякой глупой smartовости...

>А может, Вы знаете, какую строку передают в fopen? И как она из уникодного QString становится "локальной"?

Нет, не знаю. Может, Вы поясните?

Зато я знаю, что KDE работает нормально, без выкрутасов, и там, в отличи от гнома, не требуется принудительно прописать определенные переменные окружения.

Я тут пытаюсь поработать с GNOME на примере 2.6...
Кто мне скажет такую вещь? Если перезапустить иксы по Ctrl+Alt+Backspace, то гном при загрузке начинает орать, что панель уже запущена и потому запускать по новой не будет. Панель, разумеется, на экране отсутствует. Фича? Баг? Криво сконфигурировано (пока ничего не трогал, всё by default)?

Извините, не воспроизводится

> Нет, не знаю. Может, Вы поясните?

Я тоже не знаю - у меня с K-World шапочное знакомство. Потому и не спрашиваю.

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

1. Либо не быть внутри уникодным. Как gtk1 - он был честно-8-битным и прозрачным для любых 8-битных кодировок - но, вроде, под уникодом он не очень хорошо вел себя.

2. Либо быть уникодным, но выполнять конверсию перед вызовом fopen (явно или неявно - вопрос организации API). При этом возможны два варианта:

2а. Конверсия при помощи явно указанных переменных окружения (ну или чего-то подобного - файла конфигурации, ...)

2b. Конверсия при помощи эвристик (которые чреваты "осечками" в сложных случаях).

Подход gtk2 (даже не гнома) - это 2а. Кто-нибудь может мне рассказать, какой подход у kde?