Re: [bash-testers] Re: readline-5.2-1 prompt issue on cygwin

[Eric Blake]

-----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             ebb9@byu.net
-----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-----