Color in bash prompt messes up git output

Your prompt setting is incorrect, but not related at all to the git problem.

To make line editing work (i.e. to know where the cursor is after the prompt's printed), bash needs to know exactly how wide the prompt is. It cannot recognize every possible terminal-specific escape sequence out there, so it needs to be told explicitly that certain parts of the prompt are invisible; they have to be surrounded by \[ and \] codes. For example:

PS1="\[\033[1;33m\]\u@\h: \w>\[\033[m\]"

Without doing this, typing a command longer than one line will very often result in the second line overwriting the first one, and other glitches.

However, none of this affects git. The reason git log prints a ESC[33m is because git itself wants that line to be shown in yellow – it always does so when the colour option, color.ui, is enabled. The reason you see the word "ESC" instead of yellow is because your $PAGER doesn't recognize the sequence; it thinks you're reading a file with binary data (as opposed to human-readable text).

If you're using the default less pager as $PAGER, it could be that you added some custom options to the $LESS variable and forgot the one that allows colors, -R. Normally git sets $LESS internally when running a pager, but if you set that variable yourself git won't touch it and you have to add -R to it:

export LESS="R"

export LESS="e M q R F X z -3"

...or something along those lines.

user1686

Posted 2014-04-23T15:25:58.650

Reputation: 283 655

Thank you! Added export LESS="R" and it seems to have fixed it. Not sure what set $LESS or where it's set, though I do see a .lesshst file in my directory. I still see a couple ^M characters here and there in the git diff, but could just be characters in my files or something. – undefinedvariable – 2014-04-23T16:24:20.407

.lesshst doesn't keep any settings; it keeps the history of what text you searched in files (using the / or ? keys) when reading them through less. – user1686 – 2014-04-23T17:03:01.557

As for the ^M, it's shown by git diff, to alert you that the line has a CR character (carriage return) in it – in other words, that it uses Windows 'CR LF' line-endings instead of Unix 'LF' ones. ^M comes from the fact that the CR byte is the same as the "M" byte with the three highest bits reset; it's a common syntax to show the normally-invisible "control" characters. – user1686 – 2014-04-23T17:03:32.467

Yeah, I looked at the .lesshst file and it wasn't very helpful, nor did I remember doing those things. There's probably another program that uses it like git.

Thanks for clearing up the ^M. – undefinedvariable – 2014-04-23T17:45:47.880

There are many; for example, man. – user1686 – 2014-04-23T21:18:41.980

Color in bash prompt messes up git output

Answers