Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

The first two chars were repeated while I use Tab to do completion. In the screenshot below, cd is repeated.

enter image description here

I have tried rxvt-unicdoe, xterm, terminator. All these terminal emulators have this issue.

Zsh version 5.0.2, config file on-my-zsh

share|improve this question
Are the characters repeated in the command that zsh executes, or are they merely displayed? Does the number of characters change if the command is longer than two characters? Does the number change when the current directory changes? –  Gilles Sep 15 '13 at 23:02
@Gilles The repeated char not exists in the command. I can execute command. –  jilen Sep 16 '13 at 11:19

1 Answer 1

up vote 8 down vote accepted

If the characters on your command line are sometimes displayed at an offset, this is often because zsh has computed the wrong width for the prompt. The symptoms are that the display looks fine as long as you're adding characters or moving character by character but becomes garbled (with some characters appearing further right than they should) when you use other commands that move the cursor (Home, completion, etc.) or when the command overlaps a second line.

Zsh needs to know the width of the prompt in order to know where the characters of the command are placed. It assumes that each character occupies one position unless told otherwise.

One possibility is that your prompt contains escape sequences which are not properly delimited. Escape sequences that change the color or other formatting aspects of the text, or that change the window title or other effects, have zero width. They need to be included within a percent-braces construct %{…%}. More generally, an escape sequence like %42{…%} tells zsh to assume that what is inside the braces is 42 characters wide.

So check your prompt settings (PS1, PROMPT, or the variables that they reference) and make sure that all escape sequences (such as \e[…m to change text attributes — note that it may be present via some variable like $fg[red]) are inside %{…%}. Since you're using oh-my-zsh, check both your own settings and the definitions that you're using from oh-my-zsh.

The same issue arises in bash. There zero-width sequences in a prompt need to be enclosed in \[…\].

Another possibility is that your prompt contains non-ASCII characters and that zsh (or any other application) and your terminal have a different idea of how wide they are. This can happen if there is a mismatch between the encoding of your terminal and the encoding that is declared in the shell, and the two encodings result in different widths for certain byte sequences. Typically you might run into this issue when using a non-Unicode terminal but declaring a Unicode locale or vice versa.

Applications rely on environment variables to know the locale; the relevant setting is LC_CTYPE, which is determined from the environment variables LANGUAGE, LC_ALL, LC_CTYPE and LANG (the first of these that is set applies). The command locale | grep LC_CTYPE tells you your current setting. Usually the best way to avoid locale issues is to let the terminal emulator set LC_CTYPE, since it knows what encoding it expects; but if that's not working for you, make sure to set LC_CTYPE.

The same symptoms can occur when the previous command displayed some output that didn't end in a newline, so that the prompt is displayed in the middle of the line but the shell doesn't realize that. In this case that would only happen after running such a command, not persistently.

If a line isn't displayed properly, the command redisplay or clear-screen (bound to Ctrl+L by default) will fix it.

share|improve this answer
I guess I am probably missing related font, I notice the first char is strange. It is expected to be -> I think –  jilen Sep 17 '13 at 15:44
@jilen Ah, this could be another issue that I forgot to mention: maybe your prompt contains non-ASCII characters in a different encoding from your terminal, with one or both of the encodings being multibyte. If you want help with that, post the output of locale and of echo $PS1 | od -t x1 (and the same thing with any other variable used by $PS1). –  Gilles Sep 17 '13 at 15:48
I forgot to set the locale(I am using archlinux, locale are left not set by default) . After set locale , this problem are fixed. Thanks a lot, guy!!!! –  jilen Sep 17 '13 at 16:20
I upvoted it because, well, it's pretty awesome. But escapes needn't absolutely be included in the brackets if you otherwise handle the cursor count on your own. calling a subshelled function has worked for me in the past - or redirections that still land on /dev/tty without involving stdout might work. Other methods that have worked - using \e{7,8} to save/restore cursor states. –  mikeserv Jul 26 at 8:21
It was the LC_CTYPE that fixed it for me. I had it set to C, when I unset it, everything worked. Thanks. –  jmaloney Oct 29 at 14:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.