On Fri, May 20, 2005 at 10:38:09PM -0500, Kent West wrote: > Jacobo221 wrote: > > >I like customizing my PC. In my console I use the following PS1 var: > > > >PS1='\n\033[34;1m[\w]\033[0;34m\$ ' > >PS1=$PS1'\033[s\033[1;1f\033[37;47;1m\033[K Terminal: > >\033[2m\l\033[1m\033[;19fJobs: \033[2m\j\033[1m\033[;29fUser: > >\033[2m\u\033[1m\033[;45fHost: \033[2m\h\033[1m\033[;61f\d \033[2m(\A) > >\033[u' > >PS1=$PS1'\033[0m' > > > >It works fine, but the thing is that suing colour escape codes seems to > >break readline! I mean, if I use that PS1 variable, readline behaves strange. > > > > I use bash, and also have a colour-coded prompt. I see similar problems > to what you're describing. I've just learned to live with it. I only > mention this so you'll know you're not alone. Sorry I don't have a > solution for you.
There are several ingredients to getting this to work. First one is to bracket all escape/control sequences with \[ ... \]. This is required, because those sequences are considered 'non-printing'... Thus, it's a feature, not a bug -- it's in fact documented in the bash man page (section PROMPTING). Don't worry, I also suffered from a misbehaving colorized prompt for years, until I realised that subtlety... ;) This first step should suffice for all 'normal' one-line prompts. What you're trying to do (save/restore cursor position with \e[s ... \e[u ), is advanced stuff, however. Really, nothing for the faint of heart :) You are lucky, though, that I've already spent several hours of my life figuring out a similar issue. Well, mostly. The closest you can get here, I think, is the following: PS1='\n\[\e[1A\e[s\e[1;1f\e[37;47;1m\e[K\] ' PS1=$PS1'Terminal: \[\e[2m\]\l\[\e[1m\e[;19f\]' PS1=$PS1'Jobs: \[\e[2m\]\j\[\e[1m\e[;29f\]' PS1=$PS1'User: \[\e[2m\]\u\[\e[1m\e[;45f\]' PS1=$PS1'Host: \[\e[2m\]\h\[\e[1m\e[;61f\]' PS1=$PS1'\d \[\e[2m\](\A) \[\e[u\]' PS1=$PS1'\n\[\e[34;1m\][\w]\[\e[0;34m\]\$ ' (not exactly pretty, thus split across several lines for readability; also, using the shorter \e instead of \033) I'm not going to explain every last detail, but the key thing to note is that the position of the \n is determining bash's idea of where the prompt is. This doesn't seem to be documented anywhere, so it took me quite a few attempts... Good ol' trial-and-error, I tell ya whut. IOW, there's no way around putting the \n after the point where the cursor position is restored (after printing the 'status line'). Unfortunately, this has the undesired side effect of making the status line scroll out of the terminal window, when the prompt is at the very bottom -- as you probably realized yourself. So, we have to compensate for this effect, by scrolling the terminal up one line, ahead of printing the status line. As there doesn't seem to be an escape sequence for simple scrolling (at least I haven't found one), we'll have to emulate it somehow: \n\e[1A\e[s ...status line... \e[u\n ...rest of prompt... or \n <cursor up> <save cursor pos> ... <restore cursor pos> \n ... The first \n makes the window scroll, and the <cursor up> repositions the cursor to where it was before the \n. This makes sure we always have an empty line at the bottom, to finally place our prompt in... This is still not perfect, however, because the status line will still temporarily scroll out of the window, whenever a long multi-line command is retrieved from the history. But I don't think there's a workaround for this problem, as the prompt is always printed _before_ any commandline content is written. So, the commandline length is simply not yet known and may not be accounted for within the prompt code. Well... it seems to be a decent approximation, as you can now use all of the readline stuff like Ctrl-A, Ctrl-E, left/right cursor, etc., without messing up the commandline. It should work at least with rxvt (my favorite terminal emulator, btw) and xterm -- haven't tested it with other terminals, though... YMMV. Happy hacking! Almut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
