Hello. Another bug report was filled in in our bugzilla: http://bugs.gentoo.org/177095
bash-3.2 patch level 17.
If PS1 contains multibyte characters this confuses readline during
update_line. To reproduce set PS1='абвгдежзиклмноп ' and then press
Ctrl+R.
I've debuged problem a bit and although I'm not sure how to fix I'll
report my observations.
gdb shows that update_line() is called with the following arguments:
update_line (old=0x812a558 "абвгдежзиклмноп ",
new=0x8124628 "(reverse-i-search)`': ", current_line=0,
omax=31, nmax=22, inv_botlin=0)at display.c:1220
when program gets display.c:1517 col_lendiff=6 >0 and lendiff=-9. And
this negative value is passed to
1534: insert_some_chars (nfd, lendiff, col_lendiff);
which leads to output corruption. Or in English this bug is reproducible
when difference in characters (length on the screen) for new and old
buffers is positive but difference in number of bytes is negative.
To successfully reproduce bug PS1 (in bytes) should be longer then 22
(the length of '(reverse-i-search)`': ').
Note that this is also reproducible if PS1 contains \W or \w and
directory name is multibyte with the above mentioned conditions.
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
_______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
