Re: Help: не вводятсяpyсские бyквы вNetscape'е 3.Х

[Ivan Pascal <pascal@info.tsu.ru>]

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

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

> Программисту же нужно чтобы работало в стандартных системах,
> а потому он не может пойти на нарушение стандартов. Так все и должно быть.

  Ох уж эти стандарты.
Они решают только одну проблему - совместимость, и то не всегда успешно.
И плодят кучу мелких проблемок.
  В результате те, кто отступает от них могут оказаться в более выгодном
положении.
(Например, знаю историю, с одной функцией, которую в FreeBSD сделали
"по POSIX" и сразу обрезали часть возможностей. А в Linux пошли своим путем.
Теперь "у вас работает", а на FreeBSD - нет. Совместимость нарушена,
а страдают только "POSIX юзеры".)

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

 OK. Тогда надо "пропихнуть" принудительную установку локали в libc или libX11.

> >   В конце концов, когда все программы (во всех последних дистрибутивах)
> > будут доведены до ума, тогда "хак" отомрет сам собой.
> 
> Нет!!! Он останется. Посмотрите на Linux Cyrillic HOWTO. Оно уже давно неверно, но
> живет и будет жить. Более того, именно к нему отсылают новых юзеров Хаки не
> умирают, они живут в сети вечно. Наши собиратели советов не уничтожают ссылки на
> них.

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

  А во-вторых. Есть "безобидные" советы (например - поместить path к русским
шрифтам в начало списка) и "вредные" (выключить xkb, "испортить" locale).
  Данный хак - "безобидный".

> > - если это требутся только для нескольких приложений - опять же не проблема
> > запускать их через скрипт с установкой нужной переменной;
> 
> Вот мы и пришли к лечению _конкретных_ приложений_ Из-за чего же сыр-бор? Значит,
> панацеи -- нет! А если нет, то давайте лечить каждого, а не всем сразу --
> тампончик с йодом.

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

  И кроме того - если говорить конкретно.
LC_CTYPE по локали вряд ли кому мешает. Примеры есть?
А вот LC_NUMERIC сейчас мешает почти всем.

  Так что - особенно "индивидуального" подхода и не требуется.

> > - если автор такой умный и пользует setlocale с аргументами не "", то
> > тоже не проблема - setlocale(...,"") отработает при старте, а потом
> > автор "по ходу пьесы" может их поменять на "более подходящие".
> 
> То есть Вы хотите, чтобы вместо locale C по умолчанию каждая программа имела
> locale системы?

  Yessss!!! Именно этого и хочу.
Locale C пусть будет "стандартная". И кому ее надо пусть явно вызывают.
А "по умолчанию" - то что пользователь хочет.

> Ну-ну. Автор тогда должен долго думать, как ему читать
> конфигурационный файл и время. Нет, Вас явно понесло не туда.

  Хм.. Странный какой-то аргумент.
- Какие проблемы с чтением даты?
   - это не дело автора приложения, а соответствующей библиотеки
   - если она написала дату по LC_TIME, то и прочитать должна так же
   - если программа хранит где-то дату, пусть пишет ее в любом самописном
формате, вывод по locale только для human readable
   - если дату написала другая программа, то - ничего не поможет.
Если какой-то японский ftp пишет в dir дату по японски, то у меня никакая
программа не прочитает, будь в ней locale С или ru_RU.KOI8-R.
Это уже не "проблема чтения", а "проблема обмена данными".

- Какие проблемы с чтением  конфигурационного файла?
  - Если по поводу numeric, то - см. выше про дату.
  - А если ему мешает LC_TYPE, то ...
    - все "служебные" слова должны быть в portable character set, он от локали
      не зависит
    - а вот всяческие value ("лейблы", имена файлов, etc.) имеют право быть
      в любом виде. И нефиг "парсеру" лазить "внутрь ковычек".

  А кроме того, "долго думать" тоже полезно.
Может быть автор додумается, что для решения его проблем (кстати, как много
таких приложений, которым нужно читать "локалезависимые" конфиги и даты?)
нужно использовать явный вызов setlocale(<чего надо>, "C").
  Зато потом будет делать это не задумываясь.

> И все из за чего? Где у Вас проблемы с locale? Вот у меня их почти не осталось.
> Обновляйтесь!

  Хм... Надеюсь, Вы это не мне. :-)))
У меня проблем с локалью (как и с клавиатурным вводом) нет.

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

-- 
 Ivan U. Pascal         |   e-mail: pascal@tsu.ru
   Administrator of     |   Tomsk State University
     University Network |       Tomsk, Russia