1
0
mirror of https://github.com/git/git.git synced 2024-11-18 19:13:58 +01:00
git/color.c

421 lines
8.6 KiB
C
Raw Normal View History

#include "cache.h"
#include "config.h"
#include "color.h"
static int git_use_color_default = GIT_COLOR_AUTO;
int color_stdout_is_tty = -1;
/*
* The list of available column colors.
*/
const char *column_colors_ansi[] = {
GIT_COLOR_RED,
GIT_COLOR_GREEN,
GIT_COLOR_YELLOW,
GIT_COLOR_BLUE,
GIT_COLOR_MAGENTA,
GIT_COLOR_CYAN,
GIT_COLOR_BOLD_RED,
GIT_COLOR_BOLD_GREEN,
GIT_COLOR_BOLD_YELLOW,
GIT_COLOR_BOLD_BLUE,
GIT_COLOR_BOLD_MAGENTA,
GIT_COLOR_BOLD_CYAN,
GIT_COLOR_RESET,
};
/* Ignore the RESET at the end when giving the size */
const int column_colors_ansi_max = ARRAY_SIZE(column_colors_ansi) - 1;
/* An individual foreground or background color. */
struct color {
enum {
COLOR_UNSPECIFIED = 0,
COLOR_NORMAL,
COLOR_ANSI, /* basic 0-7 ANSI colors */
COLOR_256,
COLOR_RGB
} type;
/* The numeric value for ANSI and 256-color modes */
unsigned char value;
/* 24-bit RGB color values */
unsigned char red, green, blue;
};
/*
* "word" is a buffer of length "len"; does it match the NUL-terminated
* "match" exactly?
*/
static int match_word(const char *word, int len, const char *match)
{
return !strncasecmp(word, match, len) && !match[len];
}
static int get_hex_color(const char *in, unsigned char *out)
{
unsigned int val;
val = (hexval(in[0]) << 4) | hexval(in[1]);
if (val & ~0xff)
return -1;
*out = val;
return 0;
}
static int parse_color(struct color *out, const char *name, int len)
{
/* Positions in array must match ANSI color codes */
static const char * const color_names[] = {
"black", "red", "green", "yellow",
"blue", "magenta", "cyan", "white"
};
char *end;
int i;
long val;
/* First try the special word "normal"... */
if (match_word(name, len, "normal")) {
out->type = COLOR_NORMAL;
return 0;
}
/* Try a 24-bit RGB value */
if (len == 7 && name[0] == '#') {
if (!get_hex_color(name + 1, &out->red) &&
!get_hex_color(name + 3, &out->green) &&
!get_hex_color(name + 5, &out->blue)) {
out->type = COLOR_RGB;
return 0;
}
}
/* Then pick from our human-readable color names... */
for (i = 0; i < ARRAY_SIZE(color_names); i++) {
if (match_word(name, len, color_names[i])) {
out->type = COLOR_ANSI;
out->value = i;
return 0;
}
}
/* And finally try a literal 256-color-mode number */
val = strtol(name, &end, 10);
if (end - name == len) {
/*
* Allow "-1" as an alias for "normal", but other negative
* numbers are bogus.
*/
if (val < -1)
; /* fall through to error */
else if (val < 0) {
out->type = COLOR_NORMAL;
return 0;
/* Rewrite low numbers as more-portable standard colors. */
} else if (val < 8) {
out->type = COLOR_ANSI;
out->value = val;
return 0;
} else if (val < 256) {
out->type = COLOR_256;
out->value = val;
return 0;
}
}
return -1;
}
static int parse_attr(const char *name, size_t len)
{
static const struct {
const char *name;
size_t len;
int val, neg;
} attrs[] = {
#define ATTR(x, val, neg) { (x), sizeof(x)-1, (val), (neg) }
ATTR("bold", 1, 22),
ATTR("dim", 2, 22),
ATTR("italic", 3, 23),
ATTR("ul", 4, 24),
ATTR("blink", 5, 25),
ATTR("reverse", 7, 27),
ATTR("strike", 9, 29)
#undef ATTR
};
int negate = 0;
int i;
if (skip_prefix_mem(name, len, "no", &name, &len)) {
skip_prefix_mem(name, len, "-", &name, &len);
negate = 1;
}
for (i = 0; i < ARRAY_SIZE(attrs); i++) {
if (attrs[i].len == len && !memcmp(attrs[i].name, name, len))
return negate ? attrs[i].neg : attrs[i].val;
}
return -1;
}
int color_parse(const char *value, char *dst)
{
return color_parse_mem(value, strlen(value), dst);
}
void color_set(char *dst, const char *color_bytes)
{
xsnprintf(dst, COLOR_MAXLEN, "%s", color_bytes);
}
/*
* Write the ANSI color codes for "c" to "out"; the string should
* already have the ANSI escape code in it. "out" should have enough
* space in it to fit any color.
*/
static char *color_output(char *out, int len, const struct color *c, char type)
{
switch (c->type) {
case COLOR_UNSPECIFIED:
case COLOR_NORMAL:
break;
case COLOR_ANSI:
if (len < 2)
die("BUG: color parsing ran out of space");
*out++ = type;
*out++ = '0' + c->value;
break;
case COLOR_256:
out += xsnprintf(out, len, "%c8;5;%d", type, c->value);
break;
case COLOR_RGB:
out += xsnprintf(out, len, "%c8;2;%d;%d;%d", type,
c->red, c->green, c->blue);
break;
}
return out;
}
static int color_empty(const struct color *c)
{
return c->type <= COLOR_NORMAL;
}
int color_parse_mem(const char *value, int value_len, char *dst)
{
const char *ptr = value;
int len = value_len;
char *end = dst + COLOR_MAXLEN;
unsigned int attr = 0;
struct color fg = { COLOR_UNSPECIFIED };
struct color bg = { COLOR_UNSPECIFIED };
while (len > 0 && isspace(*ptr)) {
ptr++;
len--;
}
color_parse_mem: allow empty color spec Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01 01:21:29 +01:00
if (!len) {
dst[0] = '\0';
return 0;
}
if (!strncasecmp(ptr, "reset", len)) {
xsnprintf(dst, end - dst, GIT_COLOR_RESET);
return 0;
}
/* [fg [bg]] [attr]... */
while (len > 0) {
const char *word = ptr;
color_parse_mem: initialize "struct color" temporary Compiling color.c with gcc 6.2.0 using -O3 produces some -Wmaybe-uninitialized false positives: color.c: In function ‘color_parse_mem’: color.c:189:10: warning: ‘bg.blue’ may be used uninitialized in this function [-Wmaybe-uninitialized] out += xsnprintf(out, len, "%c8;2;%d;%d;%d", type, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ c->red, c->green, c->blue); ~~~~~~~~~~~~~~~~~~~~~~~~~~ color.c:208:15: note: ‘bg.blue’ was declared here struct color bg = { COLOR_UNSPECIFIED }; ^~ [ditto for bg.green, bg.red, fg.blue, etc] This is doubly confusing, because the declaration shows it being initialized! Even though we do not explicitly initialize the color components, an incomplete initializer sets the unmentioned members to zero. What the warning doesn't show is that we later do this: struct color c; if (!parse_color(&c, ...)) { if (fg.type == COLOR_UNSPECIFIED) fg = c; ... } gcc is clever enough to realize that a struct assignment from an uninitialized variable taints the destination. But unfortunately it's _not_ clever enough to realize that we only look at those members when type is set to COLOR_RGB, in which case they are always initialized. With -O2, gcc does not look into parse_color() and must assume that "c" emerges fully initialized. With -O3, it inlines parse_color(), and learns just enough to get confused. We can silence the false positive by initializing the temporary "c". This also future-proofs us against violating the type assumptions (the result would probably still be buggy, but in a deterministic way). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-31 05:43:07 +02:00
struct color c = { COLOR_UNSPECIFIED };
int val, wordlen = 0;
while (len > 0 && !isspace(word[wordlen])) {
wordlen++;
len--;
}
ptr = word + wordlen;
while (len > 0 && isspace(*ptr)) {
ptr++;
len--;
}
if (!parse_color(&c, word, wordlen)) {
if (fg.type == COLOR_UNSPECIFIED) {
fg = c;
continue;
}
if (bg.type == COLOR_UNSPECIFIED) {
bg = c;
continue;
}
goto bad;
}
val = parse_attr(word, wordlen);
if (0 <= val)
attr |= (1 << val);
else
goto bad;
}
#undef OUT
#define OUT(x) do { \
if (dst == end) \
die("BUG: color parsing ran out of space"); \
*dst++ = (x); \
} while(0)
if (attr || !color_empty(&fg) || !color_empty(&bg)) {
int sep = 0;
int i;
OUT('\033');
OUT('[');
for (i = 0; attr; i++) {
unsigned bit = (1 << i);
if (!(attr & bit))
continue;
attr &= ~bit;
if (sep++)
OUT(';');
dst += xsnprintf(dst, end - dst, "%d", i);
}
if (!color_empty(&fg)) {
if (sep++)
OUT(';');
/* foreground colors are all in the 3x range */
dst = color_output(dst, end - dst, &fg, '3');
}
if (!color_empty(&bg)) {
if (sep++)
OUT(';');
/* background colors are all in the 4x range */
dst = color_output(dst, end - dst, &bg, '4');
}
OUT('m');
}
OUT(0);
return 0;
bad:
return error(_("invalid color value: %.*s"), value_len, value);
#undef OUT
}
int git_config_colorbool(const char *var, const char *value)
{
if (value) {
if (!strcasecmp(value, "never"))
return 0;
if (!strcasecmp(value, "always"))
color: make "always" the same as "auto" in config It can be handy to use `--color=always` (or it's synonym `--color`) on the command-line to convince a command to produce color even if it's stdout isn't going to the terminal or a pager. What's less clear is whether it makes sense to set config variables like color.ui to `always`. For a one-shot like: git -c color.ui=always ... it's potentially useful (especially if the command doesn't directly support the `--color` option). But setting `always` in your on-disk config is much muddier, as you may be surprised when piped commands generate colors (and send them to whatever is consuming the pipe downstream). Some people have done this anyway, because: 1. The documentation for color.ui makes it sound like using `always` is a good idea, when you almost certainly want `auto`. 2. Traditionally not every command (and especially not plumbing) respected color.ui in the first place. So the confusion came up less frequently than it might have. The situation changed in 136c8c8b8f (color: check color.ui in git_default_config(), 2017-07-13), which negated point (2): now scripts using only plumbing commands (like add-interactive) are broken by this setting. That commit was fixing real issues (e.g., by making `color.ui=never` work, since `auto` is the default), so we don't want to just revert it. We could turn `always` into a noop in plumbing commands, but that creates a hard-to-explain inconsistency between the plumbing and other commands. Instead, let's just turn `always` into `auto` for all config. This does break the "one-shot" config shown above, but again, we're probably better to have simple and consistent rules than to try to special-case command-line config. There is one place where `always` should retain its meaning: on the command line, `--color=always` should continue to be the same as `--color`, overriding any isatty checks. Since the command-line parser also depends on git_config_colorbool(), we can use the existence of the "var" string to deterine whether we are serving the command-line or the config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-03 15:46:06 +02:00
return var ? GIT_COLOR_AUTO : 1;
if (!strcasecmp(value, "auto"))
color: delay auto-color decision until point of use When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
return GIT_COLOR_AUTO;
}
if (!var)
return -1;
/* Missing or explicit false to turn off colorization */
if (!git_config_bool(var, value))
return 0;
/* any normal truth value defaults to 'auto' */
color: delay auto-color decision until point of use When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
return GIT_COLOR_AUTO;
}
static int check_auto_color(void)
{
if (color_stdout_is_tty < 0)
color_stdout_is_tty = isatty(1);
if (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {
char *term = getenv("TERM");
if (term && strcmp(term, "dumb"))
return 1;
}
return 0;
}
color: delay auto-color decision until point of use When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
int want_color(int var)
{
/*
* NEEDSWORK: This function is sometimes used from multiple threads, and
* we end up using want_auto racily. That "should not matter" since
* we always write the same value, but it's still wrong. This function
* is listed in .tsan-suppressions for the time being.
*/
color: delay auto-color decision until point of use When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
static int want_auto = -1;
if (var < 0)
var = git_use_color_default;
color: delay auto-color decision until point of use When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
if (var == GIT_COLOR_AUTO) {
if (want_auto < 0)
want_auto = check_auto_color();
return want_auto;
}
return var;
color: delay auto-color decision until point of use When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 07:04:23 +02:00
}
int git_color_config(const char *var, const char *value, void *cb)
{
if (!strcmp(var, "color.ui")) {
git_use_color_default = git_config_colorbool(var, value);
return 0;
}
return 0;
}
void color_print_strbuf(FILE *fp, const char *color, const struct strbuf *sb)
{
if (*color)
fprintf(fp, "%s", color);
fprintf(fp, "%s", sb->buf);
if (*color)
fprintf(fp, "%s", GIT_COLOR_RESET);
}
static int color_vfprintf(FILE *fp, const char *color, const char *fmt,
va_list args, const char *trail)
{
int r = 0;
if (*color)
r += fprintf(fp, "%s", color);
r += vfprintf(fp, fmt, args);
if (*color)
r += fprintf(fp, "%s", GIT_COLOR_RESET);
if (trail)
r += fprintf(fp, "%s", trail);
return r;
}
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...)
{
va_list args;
int r;
va_start(args, fmt);
r = color_vfprintf(fp, color, fmt, args, NULL);
va_end(args);
return r;
}
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
{
va_list args;
int r;
va_start(args, fmt);
r = color_vfprintf(fp, color, fmt, args, "\n");
va_end(args);
return r;
}
int color_is_nil(const char *c)
{
return !strcmp(c, "NIL");
}