Re: 'git log' escape symbols shown as ESC[33 and ESC[m

From: Jeff King <peff@peff.net>
Date: Jan 17, 2014, 01:47 UTC
Message-ID: <20140117014758.GF7249@sigill.intra.peff.net>
In-Reply-To: <52D87A79.6060600@rawbw.com>

On Thu, Jan 16, 2014 at 04:34:01PM -0800, Yuri wrote:

Show 9 quoted lines

> When I run 'git log' on FreeBSD-9.2, I get output like this:
> ESC[33mcommit 398e78c62fd507a317de7c2abb8e25c9fac7ac9eESC[m
> Merge: 5fb8f6e d2138ba
> ...
> 
> ESC is white on black background.
> 
> Why ESC[33m aren't expanded by the terminal? Is this because git
> prints an unsupported sequence?

Are you using "less" as your pager (it is the default in git unless you have set your PAGER environment variable)? If so, do you have the "R" option set to pass through ANSI codes? Git will set this automatically in your "LESS" variable if you do not already have such a variable (but it will not touch it if you already have it set, and are missing "R").

Show 11 quoted lines

> Hex of what git writes to terminal is here:
> 0x0000 1b5b 3333 6d63 6f6d 6d69 7420 6636 6432 6136 3032 3965 6661
> 6439 6635 6334 3161 6261  |.[33mcommit f6d2a6029efad9f5c41aba|
> 0x0022 3961 3830 6131 3032 3138 6332 6333 3465 6662 1b5b 6d0a 4d65
> 7267 653a 2033 3938 6537  |9a80a10218c2c34efb.[m.Merge: 398e7|
> 
> I think it tries to print the line in yellow (color code 33), and
> prints the wrong sequence. The correct sequence would be:
> \033[1;33mString Goes Here\033[0m
> It misses "1;" in the beginning, and "0" in the end, this is why the
> sequence is not interpreted.

No, the "\033[33m" is correct. The "1;" in your string is turning on the bold attribute, and we are not trying to do that. The "0" in the reset is optional (at least according to [1]; I do not have an actual standard to reference).

But I do not think that is your problem anyway; the "ESC" you are seeing is almost certainly generated by "less" escaping the \033.

> Why does it print a wrong sequence? Is this because this is some kind
> of linuxism that doesn't work on FreeBSD maybe?

No. See above.

> Also, there are the termcap functions that allow to determine what
> does the actual terminal supports. You should first check for cap
> bits corresponding to the features you expect, if you expect
> something uncommon.

Almost every terminal supports ANSI colors. The notable exceptions is the Windows console, but we handle the translation there. If you have a terminal that actually doesn't support ANSI colors, please let us know and we can see what is going on. But I'm reasonably sure that you are just running up against the escaping in "less" here.

-Peff