git-commit-vandalism/color.c

485 lines
10 KiB
C
Raw Normal View History

#include "cache.h"
#include "config.h"
#include "color.h"
#include "hex.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,
};
enum {
COLOR_BACKGROUND_OFFSET = 10,
COLOR_FOREGROUND_ANSI = 30,
COLOR_FOREGROUND_RGB = 38,
COLOR_FOREGROUND_256 = 38,
COLOR_FOREGROUND_BRIGHT_ANSI = 90,
};
/* 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 + "default" (value = 9) */
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;
}
/*
* If an ANSI color is recognized in "name", fill "out" and return 0.
* Otherwise, leave out unchanged and return -1.
*/
static int parse_ansi_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"
};
int i;
int color_offset = COLOR_FOREGROUND_ANSI;
if (match_word(name, len, "default")) {
/*
* Restores to the terminal's default color, which may not be
* the same as explicitly setting "white" or "black".
*
* ECMA-48 - Control Functions \
* for Coded Character Sets, 5th edition (June 1991):
* > 39 default display colour (implementation-defined)
* > 49 default background colour (implementation-defined)
*
* Although not supported /everywhere/--according to terminfo,
* some terminals define "op" (original pair) as a blunt
* "set to white on black", or even "send full SGR reset"--
* it's standard and well-supported enough that if a user
* asks for it in their config this will do the right thing.
*/
out->type = COLOR_ANSI;
out->value = 9 + color_offset;
return 0;
}
if (strncasecmp(name, "bright", 6) == 0) {
color_offset = COLOR_FOREGROUND_BRIGHT_ANSI;
name += 6;
len -= 6;
}
for (i = 0; i < ARRAY_SIZE(color_names); i++) {
if (match_word(name, len, color_names[i])) {
out->type = COLOR_ANSI;
out->value = i + color_offset;
return 0;
}
}
return -1;
}
static int parse_color(struct color *out, const char *name, int len)
{
char *end;
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... */
if (parse_ansi_color(out, name, len) == 0) {
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 0-7 as more-portable standard colors. */
} else if (val < 8) {
out->type = COLOR_ANSI;
out->value = val + COLOR_FOREGROUND_ANSI;
return 0;
/* Rewrite 8-15 as more-portable aixterm colors. */
} else if (val < 16) {
out->type = COLOR_ANSI;
out->value = val - 8 + COLOR_FOREGROUND_BRIGHT_ANSI;
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);
}
/*
* 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, int background)
{
int offset = 0;
if (background)
offset = COLOR_BACKGROUND_OFFSET;
switch (c->type) {
case COLOR_UNSPECIFIED:
case COLOR_NORMAL:
break;
case COLOR_ANSI:
out += xsnprintf(out, len, "%d", c->value + offset);
break;
case COLOR_256:
out += xsnprintf(out, len, "%d;5;%d", COLOR_FOREGROUND_256 + offset,
c->value);
break;
case COLOR_RGB:
out += xsnprintf(out, len, "%d;2;%d;%d;%d",
COLOR_FOREGROUND_RGB + offset,
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 has_reset = 0;
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;
}
/* [reset] [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 (match_word(word, wordlen, "reset")) {
has_reset = 1;
continue;
}
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) \
BUG("color parsing ran out of space"); \
*dst++ = (x); \
} while(0)
if (has_reset || attr || !color_empty(&fg) || !color_empty(&bg)) {
int sep = 0;
int i;
OUT('\033');
OUT('[');
if (has_reset)
sep++;
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(';');
dst = color_output(dst, end - dst, &fg, 0);
}
if (!color_empty(&bg)) {
if (sep++)
OUT(';');
dst = color_output(dst, end - dst, &bg, 1);
}
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"))
Revert "color: make "always" the same as "auto" in config" This reverts commit 6be4595edb8e5b616c6e8b9fbc78b0f831fa2a87. That commit weakened the "always" setting of color config so that it acted as "auto". This was meant to solve regressions in v2.14.2 in which setting "color.ui=always" in the on-disk config broke scripts like add--interactive, because the plumbing diff commands began to generate color output. This was due to 136c8c8b8f (color: check color.ui in git_default_config(), 2017-07-13), which was in turn trying to fix issues caused by 4c7f1819b3 (make color.ui default to 'auto', 2013-06-10). But in weakening "always", we created even more problems, as people expect to be able to use "git -c color.ui=always" to force color (especially because some commands don't have their own --color flag). We can fix that by special-casing the command-line "-c", but now things are getting pretty confusing. Instead of piling hacks upon hacks, let's start peeling off the hacks. The first step is dropping the weakening of "always", which this revert does. Note that we could actually revert the whole series merged in by da15b78e52642bd45fd5513ab0000fdf2e58a6f4. Most of that series consists of preparations to the tests to handle the weakening of "-c color.ui=always". But it's worth keeping for a few reasons: - there are some other preparatory cleanups, like e433749d86 (test-terminal: set TERM=vt100, 2017-10-03) - it adds "--color" options more consistently in 0c88bf5050 (provide --color option for all ref-filter users, 2017-10-03) - some of the cases dropping "-c" end up being more robust and realistic tests, as in 01c94e9001 (t7508: use test_terminal for color output, 2017-10-03) - the preferred tool for overriding config is "--color", and we should be modeling that consistently We can individually revert the few commits necessary to restore some useful tests (which will be done on top of this patch). Note that this isn't a pure revert; we'll keep the test added in t3701, but mark it as failure for now. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-13 19:23:24 +02:00
return 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(int fd)
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 color_stderr_is_tty = -1;
int *is_tty_p = fd == 1 ? &color_stdout_is_tty : &color_stderr_is_tty;
if (*is_tty_p < 0)
*is_tty_p = isatty(fd);
if (*is_tty_p || (fd == 1 && pager_in_use() && pager_use_color)) {
if (!is_terminal_dumb())
return 1;
}
return 0;
}
int want_color_fd(int fd, int 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
{
/*
* 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.
*/
static int want_auto[3] = { -1, -1, -1 };
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 (fd < 1 || fd >= ARRAY_SIZE(want_auto))
BUG("file descriptor out of range: %d", fd);
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[fd] < 0)
want_auto[fd] = check_auto_color(fd);
return want_auto[fd];
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 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 UNUSED)
{
if (!strcmp(var, "color.ui")) {
git_use_color_default = git_config_colorbool(var, value);
return 0;
}
return 0;
}
int git_color_default_config(const char *var, const char *value, void *cb)
{
if (git_color_config(var, value, cb) < 0)
return -1;
return git_default_config(var, value, cb);
}
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");
}