Bug 9289

под пользователем удаление работает нормально.

с выставленным 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 ~]# _