[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
readline vs. literal \1 and \2
From: |
Eric Blake |
Subject: |
readline vs. literal \1 and \2 |
Date: |
Wed, 4 Apr 2007 20:30:03 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
A readline question recently came up on the cygwin list. The root cause of the
problem is that the cmd.com terminal accepts the sequence "\001" as a printing
character for a hollow smiley face, and the sequence "\002" as a solid smiley
face. But readline is also documented as using \1 and \2 as the invisible
sequence delimiters (so it can emit terminal escape sequences without getting
confused as to screen position).
The original bug reporter was confused when they had two smiley faces in the
prompt of lftp, a program linked against readline 5.2, and I traced it to the
fact that the user set up lftp to call
readline("\001\001\027]0;title\a\001\002> ");
instead of
readline("\001\027]0;title\a\002> ");
lftp was blindly copying the fact that in bash's parse.y, decode_prompt_string
turns \[ in PS1 into \001\001, but failed to realize that between that point
and when bash actually called readline, it also stripped the extra \001 in
expand_prompt_string(). On most terminals (such as xterm or rxvt), this
results in two invisible \001 characters being printed, but the terminal thinks
they are non-printing, so no overall damage results. But on cmd.com, the inner
two \001 characters printed, which a) showed up as unwanted smileys, and b)
messed up readline redisplay since supposedly-invisible characters actually
occupied display width.
So the original bug is fixed by changing lftp to quit emitting the two spurious
\001 when they use readline.
However, it does raise a question pertinent to this list. While the original
user found the smiley printed for \001 unwanted, I can imagine a scenario where
a user familiar with their cmd.com terminal wants to make readline
INTENTIONALLY print a smiley, without getting readline redisplay messed up.
Similarly, it is feasible to imagine a terminal that supports an escape
sequence where it is desirable to feed a literal \002 as part of the escape
sequence. Currently, readline makes it possible only to print invisible \001
and visible \002. Is it worth improving readline to add an escape sequence
such that it is ALSO possible to intentionally print a visible \001 or
invisible \002? And if this change to readline is made, then should bash's
decode_prompt_string special case PS1='\001' to result in a literal \001,
rather than the current behavior of treating it as a synonym for PS1='\['?
--
Eric Blake
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- readline vs. literal \1 and \2,
Eric Blake <=