11814 2007-05-19 21:50:25 +0400 /etc/profile.d/0lang.*sh: изменить приоритет 2012-09-11 13:14:19 +0400 1 1 4 Development Sisyphus setup unstable all Linux CLOSED WORKSFORME P2 normal --- 23155 1 lav legion 4alt aen dd1email evg glebfm hiddenman imz kharpost ldv legion mike mithraen placeholder rider shakirov swi vt vvk zerg qa-sisyphus oldest_to_newest 50417 0 lav 2007-05-19 21:50:25 +0400 При входе по ssh переназначения LANG и прочего не происходит в связи с тем, что настройки в /etc/sysconfig/i18n "перебивают" эти переменные. Вообще приоритет, как я понимаю таков: - берём переменные что по ssh переданы, если нет - берём указанное в .i18n, если нет - берём указанное в /etc/sysconfig/18n Собственно, похоже предлагается в случае уже заданной LANG выходить из скрипта 0lang сразу. 109467 1 ldv 2010-05-26 18:39:42 +0400 *** Bug 22182 has been marked as a duplicate of this bug. *** 109480 2 ldv 2010-05-26 21:33:23 +0400 Надо будет попробовать... 109500 3 repository-robot 2010-05-27 18:20:37 +0400 setup-2.2.13-alt1 -> sisyphus: * Thu May 27 2010 Dmitry V. Levin <ldv@altlinux> 2.2.13-alt1 - /etc/profile.d/lang.*sh: do not source i18n files if non-empty LANG is already set (closes: #11814). - /etc/services: updated SANE entries (closes: #13071). - /etc/inputrc: added bindings for xterm ctrl-arrows (closes: #15628). - /etc/profile.d/tmpdir.*sh: do not create ~/tmp directory (closes: #19014). - /etc/filesystems: replaced obsolete content with a comment hinting on the purpose of this file (closes: #21082). - /etc/inputrc: added bindings for history search (closes: #22570). - /etc/securetty: added xvc0 for xen virtual console (closes: #23532). 112256 4 vvk 2010-09-17 18:54:00 +0400 +if [ -n "${LANG-}" ]; then + sourced=1 Теперь имеем vvk@home ~ % echo $LANG ru_RU.UTF-8 vvk@home ~ % su - Password: root@home ~ # echo $LANG ru_RU.UTF-8 В /root/.i18n LANG=en_US.utf8 По-моему такой фикс совсем не OK. 112258 5 ldv 2010-09-17 19:08:28 +0400 (In reply to comment #4) > +if [ -n "${LANG-}" ]; then > + sourced=1 > > Теперь имеем > > vvk@home ~ % echo $LANG > ru_RU.UTF-8 > vvk@home ~ % su - > Password: > root@home ~ # echo $LANG > ru_RU.UTF-8 > > В /root/.i18n > LANG=en_US.utf8 > > По-моему такой фикс совсем не OK. 1. Я не использую "su -". 2. Как вы предлагаете удовлетворить несоместимые желания одновременно? Сделать поведение конфигурируемым? 112333 6 vvk 2010-09-20 09:42:24 +0400 (В ответ на комментарий №5) > 2. Как вы предлагаете удовлетворить несоместимые желания одновременно? Сделать > поведение конфигурируемым? Возможно, переключатель через control не помешает. 112336 7 vvk 2010-09-20 09:52:33 +0400 (В ответ на комментарий №5) > 2. Как вы предлагаете удовлетворить несоместимые желания одновременно? Сделать > поведение конфигурируемым? Возможно, переключатель через control не помешает. Но если делать системную ручку, всё равно надо решить, какое поведение должно быть по умолчанию. Раз за несколько месяцев никто не поинтересовался этим изменением, значит всех устраивает текущий вариант. А кому нужно переопределение, могут и ~/.bashrc поправить. 112591 8 lav 2010-09-23 17:39:38 +0400 Как-то за прошедшие 2 года я понял, что более предпочительным является обратное предложенному поведение: - имена локалей могут быть несовместимы между машинами (но это уже вопрос к AcceptEnv в конфиге ssh) - становиться рутом с нерутовой локалью как-то непривычно и может давать побочные эффекты 112593 9 raorn 2010-09-23 17:57:37 +0400 (In reply to comment #8) > Как-то за прошедшие 2 года я понял, что более предпочительным является обратное > предложенному поведение: Поздно, все уже привыкли и активно пользуются. 113108 10 hiddenman 2010-10-04 22:11:40 +0400 Не успел еще ощутить все "прелести" такого поведения удаленно, только обновил dekstop, но вот то, что теперь переменную LC_MESSAGES=C в ~/.i18n все дружно игнориуют - удручает. Это что теперь, как раньше редактировать свои .bashrc/.zhrc? P.S. У меня еще в .i18n прописан LANG, может в этом дело, надо проверить. 113109 11 ldv 2010-10-04 22:19:31 +0400 (In reply to comment #10) > теперь переменную LC_MESSAGES=C в ~/.i18n все дружно игнориуют Прежде чем делать свои выводы, прочитайте, пожалуйста, сперва всё, что здесь написано. 113127 12 hiddenman 2010-10-05 13:02:01 +0400 (В ответ на комментарий №11) > (In reply to comment #10) > > теперь переменную LC_MESSAGES=C в ~/.i18n все дружно игнориуют > > Прежде чем делать свои выводы, прочитайте, пожалуйста, сперва всё, что здесь > написано. Я все прочитал, но проблема была. С помощью #altlinux, "зубила и такой-то матери" выяснилось, что в случае использования GDM эти настройки в ~/.1i8n игнорируются, не знаю, почему (раньше не игнорировались). Переключился на xdm и заработало. Оставляю комментарий для тех, кто тоже столкнется с этой проблемой. 113128 13 raorn 2010-10-05 13:05:56 +0400 А точнее, gdm сам выставил локаль, минуя {/etc/sysconfig/,.}i18n 113778 14 raorn 2010-10-15 15:33:55 +0400 *** Bug 24314 has been marked as a duplicate of this bug. *** 113780 15 rider 2010-10-15 15:48:16 +0400 поиск есть, но найти не удалось, спасибо хорошему заголовку у этой ошибки. Дим, надо что-то с этим делать. сейчас приходится на всех серверах править profile.d/lang.sh убирая оттуда игнорирование ~/.i18n 114015 16 ldv 2010-10-20 01:07:22 +0400 Сперва тема была "/etc/profile.d/0lang.*sh: изменить приоритет в пользу переменных среды". Потом, через полгода после того, как изменение было реализовано внедрено, тему поменяли на "/etc/profile.d/0lang.*sh: изменить приоритет в пользу конфигурационных файлов .i18n". Когда одни хотят одного, а другие -- другого, то мне, как лично незатронутому этим вопросом, проще ничего не делать. Так что просьба заинтересованным искать консенсус. 114019 17 rider 2010-10-20 09:05:09 +0400 Дим, уже же нашли консенсунс. в конфигурационном файле прописать переменную USE_I18N и если она есть, то использовать ~/.i18n, если нет - не использовать. 114020 18 rider 2010-10-20 09:07:59 +0400 Странно что автор предложения по игнорированию локальных настроек отмалчивается. 114036 19 ldv 2010-10-20 12:46:07 +0400 (In reply to comment #17) > в конфигурационном файле прописать переменную USE_I18N и если она есть, то > использовать ~/.i18n, если нет - не использовать. В каком конфигурационном файле? 114037 20 rider 2010-10-20 13:11:28 +0400 Можно в том же /etc/sysconfig/i18n, но тогда придётся делать какую-то обвязку, сохраняющую старые значения переменных. 119313 21 swi 2011-03-16 22:23:14 +0300 приехали, здрасти. уже месяца 3 сижу на gdm и сегодня после d-u опаньки. В самом gdm усе русское, но гном уже locale = C При запуске через login && startx все в положеной utf-8. Какая зараза где что оторвала? ~/.i18n не имел с принятия в комсомо^Wгода с 2006го. 119323 22 ldv 2011-03-17 12:47:15 +0300 Вы предлагаете делать ручки по управлению ручками контроля над ручками? Я против чрезмерной косвенности. 125708 23 shakirov 2011-09-27 09:43:23 +0400 (В ответ на комментарий №5) > 1. Я не использую "su -". > 2. Как вы предлагаете удовлетворить несоместимые желания одновременно? Сделать > поведение конфигурируемым? А это нормально: login as root # locale | grep LANG LANG=POSIX # su - <username> $ locale | grep LANG LANG=POSIX but if login as <username> $ locale | grep LANG LANG=ru_RU.utf8 ? 126042 24 shakirov 2011-10-06 16:18:30 +0400 *** Bug 26423 has been marked as a duplicate of this bug. *** 126044 25 shakirov 2011-10-06 16:19:34 +0400 Дмитрий, ответьте, пожалуйста... 126045 26 ldv 2011-10-06 16:24:15 +0400 (In reply to comment #23) > (В ответ на комментарий №5) > > 1. Я не использую "su -". > > 2. Как вы предлагаете удовлетворить несоместимые желания одновременно? Сделать > > поведение конфигурируемым? > > А это нормально: > > login as root > # locale | grep LANG > LANG=POSIX > # su - <username> > $ locale | grep LANG > LANG=POSIX > > but if login as <username> > $ locale | grep LANG > LANG=ru_RU.utf8 > > ? Да, я полагаю что это вполне допустимое поведение (если закрыть глаза на то, что su - <username> не вполне безопасная операция). 126057 27 4alt 2011-10-07 10:37:57 +0400 (В ответ на комментарий №26) > Да, я полагаю что это вполне допустимое поведение (если закрыть глаза на то, > что su - <username> не вполне безопасная операция). Согласно man su : "giving the argument flag -, su is instructed to invoke the shell as a login shell". Т.е. по логике, результат su - должен быть аналогичен, как если бы вошли под username с консоли сервера. А сейчас мы имеем другое поведение. 126094 28 ldv 2011-10-09 21:11:08 +0400 (In reply to comment #27) > (В ответ на комментарий №26) > > Да, я полагаю что это вполне допустимое поведение (если закрыть глаза на то, > > что su - <username> не вполне безопасная операция). > > Согласно man su : > "giving the argument flag -, su is instructed to invoke the shell as a login > shell". Т.е. по логике, результат su - должен быть аналогичен, как если бы > вошли под username с консоли сервера. А сейчас мы имеем другое поведение. С другой стороны, результат "su -" аналогичен логину с консоли в той части, которая касается "login shell". Остальное - это вопрос вариантов трактовки, которых по данному вопросу две.