[Top][All Lists]

[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

reply via email to

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