bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Invisible characters in prompt with multi-byte support enabled


From: Alexander Becher
Subject: Invisible characters in prompt with multi-byte support enabled
Date: 11 Jul 2005 21:49:18 GMT
User-agent: slrn/0.9.8.1 (NetBSD)

Short version: bash-2.05b/lib/readline/display.c:update_line:1353
calculates _rl_last_c_pos incorrectly if multibyte support is enabled
and there are invisible characters in the line that include zero-width
characters.

Long version:

I have in my .bashrc:
PS1='\[\e[1m\]\u@\h:\w\$\[\e[0m\] '

However, there are two spaces displayed at the end of the prompt.

When I type characters and reach the end of the line, the last
character that still fits on the line is not printed and does not
advance the cursor, so the wrap offset is correct.

When I use the history to go back to a multi-line input, the display is
correct, i.e. only one space after the prompt and correct wrap-around
at end of line.

I have found out that, when I remove the space at the end of PS1, i.e.
PS1='\[\e[1m\]\u@\h:\w\$\[\e[0m\]', then the display is correct. When I
put at least five spaces at the end of the prompt, i.e.
PS1='\[\e[1m\]\u@\h:\w\$\[\e[0m\]     ', then the problem does not
occur either. When there are between one and four spaces (inclusive),
there is one space too many in the display and the wrap-around problem
described above is present.

You will notice that there are eight invisible characters in my prompt,
and that, with five or more spaces at the end, the '\e' (ESC) is no
longer among the last eight characters (which it is if there are less
than five spaces).

The problem appears always on xterm (XFree86 4.3.99.903(184)) and
sometimes on wscons (NetBSD 2.0_STABLE).

A workaround is to disable multi-byte support.

The problem is solved when I use a debugger like gdb to increase
_rl_last_c_pos manually by one after line 1353 in
lib/readline/display.c, which reads:

_rl_last_c_pos += _rl_col_width (nfd+lendiff, 0, temp-lendiff);

Why is the width of exactly this string important? Obviously, when
there are invisible, zero-width characters like '\e' in this substring,
the calculation is incorrect.

I would have loved to include a fix, but that part of readline's code
is incomprehensible to me (for the moment, at least).

Regards
Alexander
-- 
PGP key available




reply via email to

[Prev in Thread] Current Thread [Next in Thread]