git/t/t4026-color.sh

130 lines
2.8 KiB
Bash
Raw Normal View History

#!/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 00:21:29 +00:00
ESC=$(printf '\033')
color()
{
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 00:21:29 +00:00
test "$actual" = "${2:+$ESC}$2"
}
invalid_color()
{
test_must_fail git config --get-color no.such.slot "$1"
}
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 00:21:29 +00:00
test_expect_success 'empty color is empty' '
color "" ""
'
test_expect_success 'attribute before color name' '
color "bold red" "[1;31m"
'
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"
'
test_expect_success 'fg bg attr...' '
color "blue bold dim ul blink reverse" "[1;2;4;5;7;34m"
'
# 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"
'
test_expect_success '"no-" variant of negation' '
color "no-bold no-blink" "[22;25m"
'
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"
'
test_expect_success 'absurdly long color specification' '
color \
"#ffffff #ffffff bold nobold dim nodim italic noitalic
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"
'
test_expect_success '0-7 are aliases for basic ANSI color names' '
color "0 7" "[30;47m"
'
test_expect_success '256 colors' '
color "254 bold 255" "[1;38;5;254;48;5;255m"
'
test_expect_success '24-bit colors' '
color "#ff00ff black" "[38;2;255;0;255;40m"
'
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"
'
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"
'
2009-12-12 12:25:24 +00: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)' '
git config color.status.nosuchslotwilleverbedefined white &&
{ git status; ret=$?; } &&
case $ret in 0|1) : ok ;; *) false ;; esac
2009-12-12 12:25:24 +00:00
'
test_done