Re: \e in PS1

[Andy Goth]

On Tuesday, August 5, 2003 3:19 am, I wrote:
> \[\e[1;30m\][\[\e[31m\]\u\[\e[30m\]@\[\e[32m\]\h\[\e[30m\]|\[\e[34m\]\w\[\e
>[30m\]]\[\e[35m\]\$\[\e[0m\] (has a space at the end)

All the \['s and \]'s look matched to me.  Anyone see a problem?  I think I'll 
try to find the simplest PS1 that still gives me trouble.

> I \[...\] bracketed all the escape sequences, yet I still experience the
> problem described in bash FAQ E3, UNLESS I'm using TERM={linux,vt100}. 
> With TERM={xterm,rxvt,konsole} bash/readline misbehaves.  I'm not sure
> about other TERM types.

I examined the prompt expander functions looking for the source of this 
weirdness, but that's not really the right place to look since the problem is 
TERM-dependent.  I'll check rl_redisplay and its dependents later, if you 
think that's where I might find my answer.

> With PS1='[\u@\h|\w]\$ ' all the problems go away regardless of my TERM.

I think I spotted a possible problem in bash-2.05b/lib/readline/display.c .  
lip and niflp aren't touched if the prompt doesn't contain any invisible 
characters (or if the user forgot \[, heh).

--- bash-2.05b-old/lib/readline/display.c       Sat Aug  9 03:11:00 2003
+++ bash-2.05a-new/lib/readline/display.c       Sat Aug  9 03:04:16 2003
@@ -206,6 +206,10 @@
       r = savestring (pmt);
       if (lp)
        *lp = strlen (r);
+      if (lip)
+       *lip = 0; /* Is this right? */
+      if (niflp)
+       *niflp = 0;
       return r;
     }

But I'm not certain it really matters.  A little testing tells me that when I 
go from a PS1 with \[ to a PS1 without, lip and niflp cease to be updated and 
continue to give their old values.  However, everything seems to work 
regardless.

-- 
Andy Goth -+- unununium@openverse.com -+- http://ioioio.net/
Now playing: [ Aphex Twin - Quoth ]