Воспроизводится так: запустить xterm в локали UTF-8, перейти на пользователя root через su -, написать: echo "тест" (тест - на русском), выполнить, нажать стрелку вверх, удалить "ст", выполнить. Удаляется только один последний символ. у рута локаль POSIX, система установлена в ru_RU.UTF-8. Последний Sisyphus. [root@rider ~]# echo "тест" тест [root@rider ~]# echo "те" тес
под пользователем удаление работает нормально.
с выставленным LC_CTYPE=ru_RU.UTF-8 у рута всё работает нормально.
версия какая?
Воспроизводится с libreadline-5.1.4-alt1.
аналогичная проблема вылезает с нажатием клавиши HOME, для перехода в начало строки при вытаскивании строки с русским текстом из HISTORY. Только там по нажатию на HOME курсор перелезает на <количество юникодных символов в строке" левее его нормального местоположения. с LC_CTYPE, выставленным в UTF-8 локаль - также не воспроизводится.
А при чём тут тогда summary? Локаль-то не UTF-8, а POSIX. Бишь local misconfiguration или бага в том, что выставило этот POSIX. Или я опять чего-то не понимаю?
Миша прав, речь идёт о том, что локаль однобайтная, в то время как терминал мультибайтный.
Кстати, должно вылечиться тем же самым LC_CTYPE в en_US.UTF-8. Вместо которого очень хотелось бы видеть у рута ru_RU.UTF-8 или то, что выставлено в /etc/sysconfig/i18n Ибо у некоторых не установлены никакие локали кроме ru ;) Точнее говоря - у всех пользователей 3.0. Так что после обновления у них эта проблема не исчезнет.
INVALID или FIXED?
Fixed by rootfiles-alt-alt9.3
$ rpm -q rootfiles-alt rootfiles-alt-alt9.3 на branch-4.0 у меня воспроизводится: xterm su - попытка ввода и удаления русских символов в cmdline
хотя видимо может быть нужно что-то прописать в конфиг ? Обновление пакета поможет или нет ?
Баг актуален?
Вполне, воспроизводится ещё проще: LC_ALL=C bash вводим русский текст, давим backspace до упора.
(In reply to comment #14) > Вполне, воспроизводится ещё проще: > LC_ALL=C bash > вводим русский текст, давим backspace до упора. Ну да, так воспроизводится, но зачем обманывать readline? Так ведь работает правильно: LC_CTYPE=$LANG LANG=C bash
Да, но под рутом не работает с таким же диагнозом. LC_CTYPE там равен en_US.utf8, проблема воспроизводится и из под пользователя (с LC_CTYPE=en_US.utf8)
(In reply to comment #16) > Да, но под рутом не работает с таким же диагнозом. > > LC_CTYPE там равен en_US.utf8, проблема воспроизводится и из под пользователя (с > LC_CTYPE=en_US.utf8) > В том то и дело, что с правильно выставленным LC_CTYPE (у нас сейчас по умолчанию en_US.utf8) никаких артефактов я не вижу.
А давайте вы оба покажете вывод locale(1) и сверите? А то обмениваетесь информацией о локалях так, будто это карты на руках и вы не хотите их раскрывать :)
О, Миша надоумил, теперь понятно в чём проблема, но непонятно как исправлять для обновляемых систем: $ locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=C LC_CTYPE=en_US.utf8 LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=
(In reply to comment #19) > О, Миша надоумил, теперь понятно в чём проблема, но непонятно как исправлять > для обновляемых систем: > $ locale > locale: Cannot set LC_CTYPE to default locale: No such file or directory > locale: Cannot set LC_ALL to default locale: No such file or directory > LANG=C > LC_CTYPE=en_US.utf8 А в чём проблема? $ rpmquery -f /usr/lib*/locale/en_US.utf8 glibc-locales-2.9-alt2
Явно проблема в $ cat /etc/rpm/macros %_install_langs ru Я знаю как это чинить. Не знаю как чинить для старых (когда инсталятор прописывал такое) систем.
(In reply to comment #21) > Явно проблема в > $ cat /etc/rpm/macros > %_install_langs ru > > Я знаю как это чинить. Не знаю как чинить для старых (когда инсталятор > прописывал такое) систем. Не помню, installer в 4.0 это ещё прописывал? В 4.1 этого уже точно не было, см. https://bugzilla.altlinux.org/show_bug.cgi?id=14117#c14 Если всё дело в этом, то надо закрывать с resolution=NOTABUG.
Если при апгрейде 4.0->4.1 не добавлялась отсутствующая локаль, то закрывать не надо, а надо сделать добавление этой локали при апгрейде 4.1->5.0|Сизиф.
(In reply to comment #23) > Если при апгрейде 4.0->4.1 не добавлялась отсутствующая локаль, то закрывать не > надо, а надо сделать добавление этой локали при апгрейде 4.1->5.0|Сизиф. Это уже совсем другая история. Спорная, между прочим. Ибо неясно, как отличить записанное при установке от записанного вручную.
Ну, тогда хотя бы предупреждение вывести. "Ваш locale(1) показывает, что у вас нет локалей foo_FOO.BAR и baz_BAZ.BAZ. Возможно, это ошибка установщика < 4.1. Для решения этой проблемы уберите то-то оттуда-то и сделайте такое-то приплясывание".
И куда выводить такое предупреждение ? нужно что бы его однозначно увидел человек при обновлении - мимо не прошёл. На мой взгляд, проще зафиксировать необходимость установки en_US в документации и радоваться жизни.
Выплёвывать из скрипта апгрейда. Насколько я помню, это считается надёжным местом, его даже GUI-фронтэнды пользователю суют. А те, кто не смотрит на лог дист-апгрейда - те и в документацию не заглянут.
что-то вроде grep -q '^%_install_langs.*en_US' /etc/rpm/macros || \ sed -i 's/^%_install_langs .*$/&:en_US/' /etc/rpm/macros && \ apt-get reinstall glibc-locales
[root@pad ~]# echo "тест" тест [root@pad ~]# echo "те" те [root@pad ~]# locale LANG=ru_RU.UTF-8 LC_CTYPE=uk_UA.UTF-8 LC_NUMERIC=C LC_TIME=C LC_COLLATE=uk_UA.UTF-8 LC_MONETARY=C LC_MESSAGES=C LC_PAPER="ru_RU.UTF-8" LC_NAME="ru_RU.UTF-8" LC_ADDRESS="ru_RU.UTF-8" LC_TELEPHONE="ru_RU.UTF-8" LC_MEASUREMENT="ru_RU.UTF-8" LC_IDENTIFICATION="ru_RU.UTF-8" LC_ALL= [root@pad ~]# ls -l /root/.i18n -rw------- 1 root root 181 Jun 10 2010 /root/.i18n [root@pad ~]# cat /root/.i18n LANGUAGE=POSIX LANG=POSIX eval `sed -n '/^LANG=[^.[:space:]]\+\.[Uu][Tt][Ff]-\?8[[:space:]]*$/ s/LANG=.*/NEED_UNICODE=1 LC_CTYPE=en_US.utf8/p' /etc/sysconfig/i18n 2>/dev/null` ||: [root@pad ~]# rpm -qf /root/.i18n rootfiles-alt-alt11 [root@pad ~]# _
