2008-02-06 15:16:08 +03:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2008 Timo Hirvonen
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
test_description='Test diff/status color escape codes'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
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 03:21:29 +03:00
|
|
|
ESC=$(printf '\033')
|
2008-02-06 15:16:08 +03:00
|
|
|
color()
|
|
|
|
|
{
|
2010-02-28 05:56:38 +03:00
|
|
|
actual=$(git config --get-color no.such.slot "$1") &&
|
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 03:21:29 +03:00
|
|
|
test "$actual" = "${2:+$ESC}$2"
|
2008-02-06 15:16:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
invalid_color()
|
|
|
|
|
{
|
2010-02-28 05:56:38 +03:00
|
|
|
test_must_fail git config --get-color no.such.slot "$1"
|
2008-02-06 15:16:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test_expect_success 'reset' '
|
|
|
|
|
color "reset" "[m"
|
|
|
|
|
'
|
|
|
|
|
|
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 03:21:29 +03:00
|
|
|
test_expect_success 'empty color is empty' '
|
|
|
|
|
color "" ""
|
|
|
|
|
'
|
|
|
|
|
|
2008-02-06 15:16:08 +03:00
|
|
|
test_expect_success 'attribute before color name' '
|
|
|
|
|
color "bold red" "[1;31m"
|
|
|
|
|
'
|
|
|
|
|
|
2020-01-21 19:56:22 +03:00
|
|
|
test_expect_success 'aixterm bright fg color' '
|
|
|
|
|
color "brightred" "[91m"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'aixterm bright bg color' '
|
|
|
|
|
color "green brightblue" "[32;104m"
|
|
|
|
|
'
|
|
|
|
|
|
2008-02-06 15:16:08 +03:00
|
|
|
test_expect_success 'color name before attribute' '
|
|
|
|
|
color "red bold" "[1;31m"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'attr fg bg' '
|
|
|
|
|
color "ul blue red" "[4;34;41m"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'fg attr bg' '
|
|
|
|
|
color "blue ul red" "[4;34;41m"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'fg bg attr' '
|
|
|
|
|
color "blue red ul" "[4;34;41m"
|
|
|
|
|
'
|
|
|
|
|
|
2010-02-28 05:56:38 +03:00
|
|
|
test_expect_success 'fg bg attr...' '
|
|
|
|
|
color "blue bold dim ul blink reverse" "[1;2;4;5;7;34m"
|
|
|
|
|
'
|
|
|
|
|
|
parse_color: recognize "no$foo" to clear the $foo attribute
You can turn on ANSI text attributes like "reverse" by
putting "reverse" in your color spec. However, you cannot
ask to turn reverse off.
For common cases, this does not matter. You would turn on
"reverse" at the start of a colored section, and then clear
all attributes with a "reset". However, you may wish to turn
on some attributes, then selectively disable others. For
example:
git log --format="%C(bold ul yellow)%h%C(noul) %s"
underlines just the hash, but without the need to re-specify
the rest of the attributes. This can also help third-party
programs, like contrib/diff-highlight, that want to turn
some attribute on/off without disrupting existing coloring.
Note that some attribute specifications are probably
nonsensical (e.g., "bold nobold"). We do not bother to flag
such constructs, and instead let the terminal sort it out.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20 18:25:52 +03:00
|
|
|
# note that nobold and nodim are the same code (22)
|
|
|
|
|
test_expect_success 'attr negation' '
|
|
|
|
|
color "nobold nodim noul noblink noreverse" "[22;24;25;27m"
|
|
|
|
|
'
|
|
|
|
|
|
2016-06-23 20:38:44 +03:00
|
|
|
test_expect_success '"no-" variant of negation' '
|
|
|
|
|
color "no-bold no-blink" "[22;25m"
|
|
|
|
|
'
|
|
|
|
|
|
2010-02-28 05:56:38 +03:00
|
|
|
test_expect_success 'long color specification' '
|
|
|
|
|
color "254 255 bold dim ul blink reverse" "[1;2;4;5;7;38;5;254;48;5;255m"
|
|
|
|
|
'
|
|
|
|
|
|
parse_color: recognize "no$foo" to clear the $foo attribute
You can turn on ANSI text attributes like "reverse" by
putting "reverse" in your color spec. However, you cannot
ask to turn reverse off.
For common cases, this does not matter. You would turn on
"reverse" at the start of a colored section, and then clear
all attributes with a "reset". However, you may wish to turn
on some attributes, then selectively disable others. For
example:
git log --format="%C(bold ul yellow)%h%C(noul) %s"
underlines just the hash, but without the need to re-specify
the rest of the attributes. This can also help third-party
programs, like contrib/diff-highlight, that want to turn
some attribute on/off without disrupting existing coloring.
Note that some attribute specifications are probably
nonsensical (e.g., "bold nobold"). We do not bother to flag
such constructs, and instead let the terminal sort it out.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20 18:25:52 +03:00
|
|
|
test_expect_success 'absurdly long color specification' '
|
|
|
|
|
color \
|
2016-06-23 20:39:07 +03:00
|
|
|
"#ffffff #ffffff bold nobold dim nodim italic noitalic
|
2016-06-23 20:40:16 +03:00
|
|
|
ul noul blink noblink reverse noreverse strike nostrike" \
|
|
|
|
|
"[1;2;3;4;5;7;9;22;23;24;25;27;29;38;2;255;255;255;48;2;255;255;255m"
|
parse_color: recognize "no$foo" to clear the $foo attribute
You can turn on ANSI text attributes like "reverse" by
putting "reverse" in your color spec. However, you cannot
ask to turn reverse off.
For common cases, this does not matter. You would turn on
"reverse" at the start of a colored section, and then clear
all attributes with a "reset". However, you may wish to turn
on some attributes, then selectively disable others. For
example:
git log --format="%C(bold ul yellow)%h%C(noul) %s"
underlines just the hash, but without the need to re-specify
the rest of the attributes. This can also help third-party
programs, like contrib/diff-highlight, that want to turn
some attribute on/off without disrupting existing coloring.
Note that some attribute specifications are probably
nonsensical (e.g., "bold nobold"). We do not bother to flag
such constructs, and instead let the terminal sort it out.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-20 18:25:52 +03:00
|
|
|
'
|
|
|
|
|
|
2015-01-21 01:14:48 +03:00
|
|
|
test_expect_success '0-7 are aliases for basic ANSI color names' '
|
|
|
|
|
color "0 7" "[30;47m"
|
|
|
|
|
'
|
|
|
|
|
|
2020-01-21 19:56:23 +03:00
|
|
|
test_expect_success '8-15 are aliases for aixterm color names' '
|
|
|
|
|
color "12 13" "[94;105m"
|
|
|
|
|
'
|
|
|
|
|
|
2008-02-06 15:16:08 +03:00
|
|
|
test_expect_success '256 colors' '
|
|
|
|
|
color "254 bold 255" "[1;38;5;254;48;5;255m"
|
|
|
|
|
'
|
|
|
|
|
|
2014-11-20 18:25:39 +03:00
|
|
|
test_expect_success '24-bit colors' '
|
|
|
|
|
color "#ff00ff black" "[38;2;255;0;255;40m"
|
|
|
|
|
'
|
|
|
|
|
|
2014-11-20 18:16:09 +03:00
|
|
|
test_expect_success '"normal" yields no color at all"' '
|
|
|
|
|
color "normal black" "[40m"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success '-1 is a synonym for "normal"' '
|
|
|
|
|
color "-1 black" "[40m"
|
|
|
|
|
'
|
|
|
|
|
|
2008-02-06 15:16:08 +03:00
|
|
|
test_expect_success 'color too small' '
|
|
|
|
|
invalid_color "-2"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'color too big' '
|
|
|
|
|
invalid_color "256"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'extra character after color number' '
|
|
|
|
|
invalid_color "3X"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'extra character after color name' '
|
|
|
|
|
invalid_color "redX"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'extra character after attribute' '
|
|
|
|
|
invalid_color "dimX"
|
|
|
|
|
'
|
|
|
|
|
|
ignore unknown color configuration
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-12 15:25:24 +03:00
|
|
|
test_expect_success 'unknown color slots are ignored (diff)' '
|
|
|
|
|
git config color.diff.nosuchslotwilleverbedefined white &&
|
|
|
|
|
git diff --color
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unknown color slots are ignored (branch)' '
|
|
|
|
|
git config color.branch.nosuchslotwilleverbedefined white &&
|
|
|
|
|
git branch -a
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'unknown color slots are ignored (status)' '
|
2015-03-20 13:12:29 +03:00
|
|
|
git config color.status.nosuchslotwilleverbedefined white &&
|
|
|
|
|
{ git status; ret=$?; } &&
|
|
|
|
|
case $ret in 0|1) : ok ;; *) false ;; esac
|
ignore unknown color configuration
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-12 15:25:24 +03:00
|
|
|
'
|
|
|
|
|
|
2008-02-06 15:16:08 +03:00
|
|
|
test_done
|
