Sunday, February 3, 2013

iTerm2 / Bash Line Wrap Bug

UPDATE: Apologies. Looks like this is not a bug. It is an expected behavior. And I failed to read through the documentation properly. Thanks to Jorge for pointing this out. Here is what he replied as you can see in one of the comments below:


    I filed a bug to the iTerm people, and they quickly replied. It turns out is not a bug, just a bash idiosyncrasy. The iTerm2 developers pointed me to this link, where it is clear that the solution is to modify PS1, and surround the non-printing chars between '\[' and '\]', to tell the shell "everything between these escaped square brackets, including the brackets themselves, is a non-printing character.

    I have been using iTerm2 for about some 8 months now. It is the tool that I use for most of my day's work. I kind of dislike IDEs and GUIs. Honestly, I feel that they are sluggish. I love to work on terminal with Vim / Emacs. All these days, I have been ignoring a bug. A bug that is caused by the line that is longer than the width of terminal. And this bug is caused only when you customize the color of your command prompt (PS1). You can have a look at my .bash_profile file. in the first line, I have customized my PS1 as follows:

    `export PS1="\e[1;36m\W\e[m \e[1;35m>\e[m "`

    Lately, I had to break up long lines using `\`. But I sooner found that this was messing up the history too. When you scroll through the history, you can see some weird stuffs happening. Got me really annoyed. Having been annoyed enough, I decided to fix this. I went to iTerm2's GitHub repo. I checked the issue list, there was no issue like that. So I forked the repo and tried running through the source code myself and fix this bug. I went through the code, and there was nothing that I could really find to fix this. Then I had to rely on my old friends Google and StackOverflow. After some lame results, I landed on a SO page where this bug was explained. Looks like it was not an issue with iTerm, but with bash itself. You see, the bash counts the prompt symbols to determine the total line length and breaks the line according to width of terminal and line width. When you set a color \e[1;36m\e[m \e[1;35m[m which is equivalent to blue and pink, bash tends to treat them printable characters and cont it along with the command prompt. While the truth is it does not add length to command prompt, it just adds up color which is not countable. This messes up the buffer and causes the line wrap bug. So I have temporarily changed my prompt to just

    `export PS1=" \W > "`

without any color. I ll wait for some time. If no one else fixes this, I ll have to do it myself. I really need the prompt color. Because, for me, it is a visual distinction between the consecutive commands. I will post my update if I ever fix it. So for now, if you experience this bug, just delete all the colors. And send me a mail, I ll reply you If I happen to fix this.

3 comments:

  1. I'm experiencing the same bug, and also need the colored prompt. Please let me know if/when you fix it.

    ReplyDelete
    Replies
    1. I filed a bug to the iTerm people, and they quickly replied. It turns out is not a bug, just a bash idiosyncrasy. The iTerm2 developers pointed me to this link, where it is clear that the solution is to modify PS1, and surround the non-printing chars between '\[' and '\]', to tell the shell "everything between these escaped square brackets, including the brackets themselves, is a non-printing character."

      Delete
    2. Hey, Jorge!

      Thanks for the reply.

      Delete