0

I'm running OSX Lion 10.7.3, zsh version 4.3.11. I've found that if I have color escape codes in my prompt, it royally screws things up. For instance, if I scroll forward through the command history to a long line, and then scroll back to a shorter one, many of the characters won't be cleared. If I had to guess, it is counting the number of visible characters, and then using that to determine how many characters ahead to clear - which wouldn't clear enough characters, of course.

For what it's worth, Ruby's Readline package exhibits the same behavior (which means I can't have colors in my irb prompt either).

bash behaves perfectly, so I'm not sure what's going on. I assume bash and zsh are both using readline... so I don't see what gives.

Any help would be greatly appreciated.

Update 3/19/12

I tried both the system zsh and the one installed via brew install zsh - no dice either way.

Here's the output of otool -L /usr/local/Cellar/zsh/4.3.17/bin/zsh:

/usr/local/Cellar/zsh/4.3.17/bin/zsh:
    /usr/local/lib/libgdbm.4.dylib (compatibility version 5.0.0, current version 5.0.0)
    /usr/local/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)

Part of me wonders if it's a problem with libncurses, as I assume that's what is used the completion and history functionality.

Charles
  • 286

1 Answers1

0

Whoops - I needed to surround the color codes with %{ and %}, as mentioned here:

Strange zsh autocomplete behaviour

So, if I wanted a portion of the prompt to be blue, it might look like this:

  export PS1=$'%{$fg[blue]%}${PWD/#$HOME/~}%{$reset_color%} %{$fg[red]%}→%{$reset_color%}'

That would look something like ~/src →.

Community
  • 1
Charles
  • 286