-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Chet Ramey on 10/4/2006 8:56 PM:
>>> $ export PS1='[\[\e[32m\]\h\[\e[0m\]:\[\e[33m\]\w\[\e[0m\]] '
>>> [LOUNGE:~/bash-3.2] cd /c^L
>>> [LOUNGE:~/bash-3.2] cd /cc
>>> ^
>>> This is what's displayed, after the ^L clears the screen; note the extra c.
>
>> I'm really at a loss as to how to go about debugging this, and don't know
>> whether the bug is in readline or in cygwin's terminal descriptions.
>> Any hints on what I should try from within a debugger?
>
> Attach to it from another terminal and set breakpoints in
> _rl_move_cursor_relative.
OK, I found something interesting. This is in a locale where MB_CUR_MAX
== 1. Immediately after hitting ^L, _rl_last_c_pos == 0, so the entire
prompt needs to be redrawn. Starting from this backtrace:
(gdb) bt
#0 _rl_output_some_chars (
string=0x88dff0 "[\033[32mLOUNGE\033[0m:\033[33m~/bash-3.2\033[0m] cd
/c",
count=25) at terminal.c:621
#1 0x00479d35 in update_line (old=0x88cfe8 "",
new=0x88dff0 "[\033[32mLOUNGE\033[0m:\033[33m~/bash-3.2\033[0m] cd /c",
current_line=0, omax=0, nmax=43, inv_botlin=0) at display.c:1531
#2 0x004789c6 in rl_redisplay () at display.c:915
#3 0x0047a1b2 in rl_forced_update_display () at display.c:1706
#4 0x0047475b in rl_clear_screen (count=1, key=12) at text.c:561
#5 0x0046447a in _rl_dispatch_subseq (key=12, map=0x48fec0, got_subseq=0)
at readline.c:737
#6 0x004642b7 in _rl_dispatch (key=12, map=0x48fec0) at readline.c:687
#7 0x00464013 in readline_internal_char () at readline.c:519
#8 0x0046405d in readline_internal_charloop () at readline.c:545
#9 0x00464077 in readline_internal () at readline.c:559
#10 0x00463be3 in readline (
prompt=0x88f8a0
"[\001\033[32m\002LOUNGE\001\033[0m\002:\001\033[33m\002~/bash-3.2\001\033[0m\002]
") at readline.c:321
So, update_line calls _rl_output_some_chars twice, once with the first 25
characters (the same length as the visible characters among the 43), then
again with the remaining 18 characters. But then it calls _rl_col_width
on the remaining 18 characters, which returns only 17, since the \033 is
non-printing. Somehow, readline has lost track of the fact that the last
18 characters of the 43 still contain invisible characters; _rl_last_c_pos
is only 42 at the end of update_line. Then in rl_redisplay, line 930,
since MB_CUR_MAX == 1, _rl_last_c_pos is not adjusted, even though it is
not an accurate absolute cursor position; with the result that at line
1053, _rl_move_cursor_relative is called once again, and prints the
duplicate c.
This patch fixes this particular test case for me, but I have no idea if
it is correct or breaks something else. The idea is that even when
MB_CUR_MAX == 1, the cursor absolute position as calculated by
_rl_col_width might not be accurate in the presence of invisible
characters passed to mbrtowc. Perhaps an alternative patch would be to
update _rl_col_width to do naive processing when MB_CUR_MAX == 1 in order
to match the assumptions of the rest of readline.
- --- bash-3.2-orig/lib/readline/display.c 2006-09-14 12:20:12.000000000
-0600
+++ bash-3.2/lib/readline/display.c 2006-11-09 21:55:21.139625000 -0700
@@ -927,7 +927,7 @@ rl_redisplay ()
time update_line is called, then we can assume in our
calculations that o_cpos does not need to be adjusted by
wrap_offset. */
- - if (linenum == 0 && (MB_CUR_MAX > 1 && rl_byte_oriented ==
0) &&
+ if (linenum == 0 && (/*MB_CUR_MAX > 1 &&*/ rl_byte_oriented
== 0) &&
cpos_adjusted == 0 &&
_rl_last_c_pos != o_cpos &&
_rl_last_c_pos > wrap_offset &&
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFVAhi84KuGfSFAYARAvKiAJ9XG3oSyIh8RX7Y+0DQWREQgvq6DgCgzQKr
XZywrLxycLjEtao55M9VpQ8=
=hT0t
-----END PGP SIGNATURE-----
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
