From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:08
This patch series makes '-x' tracing of tests work reliably even when
running them with /bin/sh, and setting TEST_SHELL_PATH=bash will be
unnecessary.
make GIT_TEST_OPTS='-x --verbose-log' test
passes on my setup and on all Travis CI build jobs (though neither me
nor Travis CI run all tests, e.g. CVS).
The first patch is the most important: with a couple of well-placed file
descriptor redirections it ensures that the stderr of the test helper
functions running git commands only contain the stderr of the tested
command, thereby resolving over 90% of the failures resulting from
running the test suite with '-x' and /bin/sh.
Most of the following patches resolve the remaining failures, one test
script at a time, in most cases by limiting the scope of stderr
redirections from functions and subshells to the tested git commands.
Except the second and ninth patches, which, arguably, could be
considered as cheating... I admit, my enthusiasm suddenly run out when
I saw t1510 :)
The last two patches are just finishing touches with a bit of
documentation updates and enabling '-x' tracing in Travis CI build jobs.
There is currently nothing in 'pu' that would require additional fixes
to make this patch series work.
SZEDER Gábor (11):
t: prevent '-x' tracing from interfering with test helpers' stderr
t: add means to disable '-x' tracing for individual test scripts
t1507-rev-parse-upstream: don't check the stderr of a shell function
t3030-merge-recursive: don't check the stderr of a subshell
t5500-fetch-pack: don't check the stderr of a subshell
t5526: use $TRASH_DIRECTORY to specify the path of GIT_TRACE log file
t5570-git-daemon: don't check the stderr of a subshell
t9903-bash-prompt: don't check the stderr of __git_ps1()
t1510-repo-setup: mark as untraceable with '-x'
t/README: add a note about don't saving stderr of compound commands
travis-ci: run tests with '-x' tracing
ci/lib-travisci.sh | 2 +-
t/README | 23 +++++++++++++++++++---
t/lib-terminal.sh | 4 ++--
t/t1507-rev-parse-upstream.sh | 14 +++++++-------
t/t1510-repo-setup.sh | 4 ++++
t/t3030-merge-recursive.sh | 36 +++++++++++++++++++----------------
t/t5500-fetch-pack.sh | 12 ++++++------
t/t5526-fetch-submodules.sh | 2 +-
t/t5570-git-daemon.sh | 2 +-
t/t9903-bash-prompt.sh | 14 ++------------
t/test-lib-functions.sh | 24 +++++++++++------------
t/test-lib.sh | 19 +++++++++++++++++-
12 files changed, 94 insertions(+), 62 deletions(-)
--
2.16.2.400.g911b7cc0da
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:16
The previous patch resolved most of the test failures caused by
running our test suite with '-x' tracing and /bin/sh, and the
following patches in this series will resolve almost all of the
remaining failures. Unfortunately, not yet all.
Add means to disable '-x' tracing for individual test scripts by
setting the $test_untraceable variable to a non-empty value in the
test script before sourcing 'test-lib.sh'. However, since '-x'
tracing is not an issue with recent Bash versions supporting
BASH_XTRACEFD, i.e. v4.1 and later, don't disable tracing when the
test script is run with such a Bash version even when
$test_untraceable is set.
Signed-off-by: SZEDER Gábor <redacted>
---
t/README | 3 +++
t/test-lib.sh | 19 ++++++++++++++++++-
2 files changed, 21 insertions(+), 1 deletion(-)
@@ -87,6 +87,9 @@ appropriately before running "make". themselves. Implies `--verbose`. Note that in non-bash shells, this can cause failures in some tests which redirect and test the output of shell functions. Use with caution.+ Ignored in test scripts that set the variable 'test_untraceable'+ to a non-empty value, unless it's run with a Bash version+ supporting BASH_XTRACEFD, i.e. v4.1 or later. -d:: --debug::
@@ -263,7 +263,24 @@ doGIT_TEST_CHAIN_LINT=0shift;;-x)-trace=t+# Some test scripts can't be reliably traced with '-x',+# unless the test is run with a Bash version supporting+# BASH_XTRACEFD (introduced in Bash v4.1). Check whether+# this test is marked as such, and ignore '-x' if it+# isn't executed with a suitable Bash version.+iftest-z"$test_untraceable"||{+test-n"$BASH_VERSION"&&{+test${BASH_VERSINFO[0]}-gt4||{+test${BASH_VERSINFO[0]}-eq4&&+test${BASH_VERSINFO[1]}-ge1+}+}+}+then+trace=t+else+echo>&2"warning: ignoring -x; '$0' is untraceable without BASH_XTRACEFD"+fishift;;--verbose-log)verbose_log=t
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:19
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <redacted>
---
t/lib-terminal.sh | 4 ++--
t/test-lib-functions.sh | 24 ++++++++++++------------
2 files changed, 14 insertions(+), 14 deletions(-)
@@ -644,7 +644,7 @@ test_must_fail () {return1fireturn0-}+}7>&22>&4# Similar to test_must_fail, but tolerates success, too. This is# meant to be used in contexts like:
@@ -658,8 +658,8 @@ test_must_fail () {# because we want to notice if it fails due to segv. test_might_fail(){-test_must_failok=success"$@"-}+test_must_failok=success"$@"2>&7+}7>&22>&4# Similar to test_must_fail and test_might_fail, but check that a# given command exited with a given exit code. Meant to be used as:
@@ -680,7 +680,7 @@ test_expect_code () {echo>&2"test_expect_code: command exited with $exit_code, we wanted $want_code$*"return1-}+}7>&22>&4# test_cmp is a helper function to compare actual and expected output.# You can use it like:
@@ -882,8 +882,8 @@ test_write_lines () {} perl(){-command"$PERL_PATH""$@"-}+command"$PERL_PATH""$@"2>&7+}7>&22>&4# Is the value one of the various ways to spell a boolean true/false? test_normalize_bool(){
@@ -1023,13 +1023,13 @@ test_env () {shift;;*)-"$@"+"$@"2>&7exit;;esacdone)-}+}7>&22>&4# Returns true if the numeric exit code in "$2" represents the expected signal# in "$1". Signals should be given numerically.
@@ -1071,9 +1071,9 @@ nongit () {GIT_CEILING_DIRECTORIES=$(pwd)&&exportGIT_CEILING_DIRECTORIES&&cdnon-repo&&-"$@"+"$@"2>&7)-}+}7>&22>&4# convert stdin to pktline representation; note that empty input becomes an# empty packet, not a flush packet (for that you can just print 0000 yourself).
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:21
Three tests in 't1507-rev-parse-upstream.sh' fail when the test script
is run with '-x' tracing (and using a shell other than a Bash version
supporting BASH_XTRACEFD). The reason for those failures is that the
tests check the stderr of the function 'error_message', which includes
the trace of commands executed in that function as well, throwing off
the comparison with the expected output.
Save stderr of 'git rev-parse' only instead of the whole function, so
it remains free from tracing output.
After this change t1507 passes with '-x', even when running with
/bin/sh.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t1507-rev-parse-upstream.sh | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
@@ -42,7 +42,7 @@ commit_subject () { error_message(){(cdclone&&-test_must_failgitrev-parse--verify"$@")+test_must_failgitrev-parse--verify"$@"2>../error)} test_expect_success'@{upstream} resolves to correct full name''
@@ -159,8 +159,8 @@ test_expect_success 'branch@{u} error message when no upstream' 'cat>expect<<-EOF&&fatal:noupstreamconfiguredforbranch${sq}non-tracking${sq}EOF-error_messagenon-tracking@{u}2>actual&&-test_i18ncmpexpectactual+error_messagenon-tracking@{u}&&+test_i18ncmpexpecterror' test_expect_success'@{u} error message when no upstream''
@@ -175,8 +175,8 @@ test_expect_success 'branch@{u} error message with misspelt branch' 'cat>expect<<-EOF&&fatal:nosuchbranch:${sq}no-such-branch${sq}EOF-error_messageno-such-branch@{u}2>actual&&-test_i18ncmpexpectactual+error_messageno-such-branch@{u}&&+test_i18ncmpexpecterror' test_expect_success'@{u} error message when not on a branch''
@@ -192,8 +192,8 @@ test_expect_success 'branch@{u} error message if upstream branch not fetched' 'cat>expect<<-EOF&&fatal:upstreambranch${sq}refs/heads/side${sq}notstoredasaremote-trackingbranchEOF-error_messagebad-upstream@{u}2>actual&&-test_i18ncmpexpectactual+error_messagebad-upstream@{u}&&+test_i18ncmpexpecterror' test_expect_success'pull works when tracking a local branch''
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:24
Three "missing reference" tests in 't5500-fetch-pack.sh' fail when the
test script is run with '-x' tracing (and using a shell other than a
Bash version supporting BASH_XTRACEFD). The reason for those failures
is that the tests check a subshell's stderr, which includes the trace
of executing commands in that subshell as well, throwing off the
comparison with the expected output.
Save the stderr of 'git fetch-pack' only instead of the whole
subshell, so it remains free from tracing output.
After this change t5500 passes with '-x', even when running with
/bin/sh.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t5500-fetch-pack.sh | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:26
The test 'no-op fetch without "-v" is quiet' in 't5570-git-daemon.sh'
fails when the test script is run with '-x' tracing (and using a shell
other than a Bash version supporting BASH_XTRACEFD). The reason for
the failure is that the test checks the emptiness of a subshell's
stderr, which includes the trace of commands executed in that subshell
as well, throwing off the emptiness check.
Save the stderr of 'git fetch' only instead of the whole subshell's, so
it remains free from tracing output.
After this change t5570 passes with '-x', even when running with
/bin/sh.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t5570-git-daemon.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -50,7 +50,7 @@ test_expect_success 'no-op fetch -v stderr is as expected' '' test_expect_success'no-op fetch without "-v" is quiet''-(cdclone&&gitfetch)2>stderr&&+(cdclone&&gitfetch2>../stderr)&&!test-sstderr'
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:29
Now that the test suite runs successfully with '-x' tracing even with
/bin/sh, enable it on Travis CI in order to
- get more information about test failures, and
- catch constructs breaking '-x' with /bin/sh sneaking into our test
suite.
Signed-off-by: SZEDER Gábor <redacted>
---
ci/lib-travisci.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:32
The two test checking 'git mmerge-recursive' in an empty worktree in
't3030-merge-recursive.sh' fail when the test script is run with '-x'
tracing (and using a shell other than a Bash version supporting
BASH_XTRACEFD). The reason for those failures is that the tests check
the emptiness of a subshell's stderr, which includes the trace of
commands executed in that subshell as well, throwing off the emptiness
check.
Note that both subshells execute four git commands each, meaning that
checking the emptiness of the whole subshell implicitly ensures that
not only 'git merge-recursive' but none of the other three commands
outputs anything to their stderr. Note also that if one of those
commands were to output anything on its stderr, then the current
combined check would not tell us which one of those four commands the
unexpected output came from.
Save the stderr of those four commands only instead of the whole
subshell, so it remains free from tracing output, and save and check
them individually, so they will show us from which command the
unexpected output came from.
After this change t3030 passes with '-x', even when running with
/bin/sh.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t3030-merge-recursive.sh | 36 ++++++++++++++++++++----------------
1 file changed, 20 insertions(+), 16 deletions(-)
@@ -525,20 +525,22 @@ test_expect_success 'merge-recursive w/ empty work tree - ours has rename' 'GIT_INDEX_FILE="$PWD/ours-has-rename-index"&&exportGIT_INDEX_FILE&&mkdir"$GIT_WORK_TREE"&&-gitread-tree-i-m$c7&&-gitupdate-index--ignore-missing--refresh&&-gitmerge-recursive$c0--$c7$c3&&-gitls-files-s>actual-files-)2>actual-err&&->expected-err&&+gitread-tree-i-m$c72>actual-err&&+test_must_be_emptyexpected-err&&+gitupdate-index--ignore-missing--refresh2>actual-err&&+test_must_be_emptyexpected-err&&+gitmerge-recursive$c0--$c7$c32>actual-err&&+test_must_be_emptyexpected-err&&+gitls-files-s>actual-files2>actual-err&&+test_must_be_emptyexpected-err+)&&cat>expected-files<<-EOF&&100644$o30b/c100644$o00c100644$o00d/e100644$o00eEOF-test_cmpexpected-filesactual-files&&-test_cmpexpected-erractual-err+test_cmpexpected-filesactual-files' test_expect_success'merge-recursive w/ empty work tree - theirs has rename''
@@ -548,20 +550,22 @@ test_expect_success 'merge-recursive w/ empty work tree - theirs has rename' 'GIT_INDEX_FILE="$PWD/theirs-has-rename-index"&&exportGIT_INDEX_FILE&&mkdir"$GIT_WORK_TREE"&&-gitread-tree-i-m$c3&&-gitupdate-index--ignore-missing--refresh&&-gitmerge-recursive$c0--$c3$c7&&-gitls-files-s>actual-files-)2>actual-err&&->expected-err&&+gitread-tree-i-m$c32>actual-err&&+test_must_be_emptyexpected-err&&+gitupdate-index--ignore-missing--refresh2>>actual-err&&+test_must_be_emptyexpected-err&&+gitmerge-recursive$c0--$c3$c72>>actual-err&&+test_must_be_emptyexpected-err&&+gitls-files-s>actual-files2>>actual-err&&+test_must_be_emptyexpected-err+)&&cat>expected-files<<-EOF&&100644$o30b/c100644$o00c100644$o00d/e100644$o00eEOF-test_cmpexpected-filesactual-files&&-test_cmpexpected-erractual-err+test_cmpexpected-filesactual-files' test_expect_success'merge removes empty directories''
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:33
Explain in 't/README' why it is a bad idea to redirect and verify the
stderr of compound commands, in the hope that future contributions
will follow this advice and the test suite will keep working with '-x'
tracing and /bin/sh.
While at it, since we can now run the test suite with '-x' without
needing a Bash version supporting BASH_XTRACEFD, remove the now
outdated caution note about non-Bash shells from the description of
the '-x' option.
Signed-off-by: SZEDER Gábor <redacted>
---
t/README | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
@@ -84,9 +84,7 @@ appropriately before running "make". -x:: Turn on shell tracing (i.e., `set -x`) during the tests- themselves. Implies `--verbose`. Note that in non-bash shells,- this can cause failures in some tests which redirect and test- the output of shell functions. Use with caution.+ themselves. Implies `--verbose`. Ignored in test scripts that set the variable 'test_untraceable' to a non-empty value, unless it's run with a Bash version supporting BASH_XTRACEFD, i.e. v4.1 or later.
@@ -455,6 +453,22 @@ Don't: causing the next test to start in an unexpected directory. Do so inside a subshell if necessary.+ - save and verify the standard error of compound commands, i.e. group+ commands, subshells, and shell functions (except test helper+ functions like 'test_must_fail') like this:++ ( cd dir && git cmd ) 2>error &&+ test_cmp expect error++ When running the test with '-x' tracing, then the trace of commands+ executed in the compound command will be included in standard error+ as well, quite possibly throwing off the subsequent checks examining+ the output. Instead, save only the relevant git command's standard+ error:++ ( cd dir && git cmd 2>../error ) &&+ test_cmp expect error+ - Break the TAP output The raw output from your test may be interpreted by a TAP harness. TAP
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:40
A test in 't9903-bash-prompt.sh' fails when the test script is run
with '-x' tracing and a Bash version not yet supporting BASH_XTRACEFD,
notably the default Bash version shipped in OSX. The reason for the
failure is that the test checks the emptiness of __git_ps1()'s stderr,
which includes the trace of all commands executed within __git_ps1()
as well, throwing off the emptiness check.
Having only a single test checking the empty stderr doesn't bring us
much when none of the other tests do so, so remove this test for now.
After this change t9903 passes with '-x', even when running with a
Bash version not yet supporing BASH_XTRACEFD.
In the future we might want to consider checking the emptiness of
__git_ps1()'s stderr in each and every test, in which case we'd have
to mark this test script as 'test_untraceable', but that's a different
topic.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t9903-bash-prompt.sh | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:41
The test 'fetch --recurse-submodules -j2 has the same output
behaviour' in 't5526-fetch-submodules.sh' fails when the test script
is run with '-x' tracing (and using a shell other than a Bash version
supporting BASH_XTRACEFD). The reason of that failure is the
following command:
GIT_TRACE=$(pwd)/../trace.out git fetch <...> 2>../actual.err
because the trace of executing 'pwd' in the command substitution ends
up in 'actual.err' as well, throwing off the subsequent
'test_i18ncmp'.
Use $TRASH_DIRECTORY to specify the path of the GIT_TRACE log file
instead of $(pwd), so the command's stderr remains free from tracing
output.
After this change t5526 passes with '-x', even when running with
/bin/sh.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t5526-fetch-submodules.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -85,7 +85,7 @@ test_expect_success "fetch --recurse-submodules -j2 has the same output behaviouadd_upstream_commit&&(cddownstream&&-GIT_TRACE=$(pwd)/../trace.outgitfetch--recurse-submodules-j22>../actual.err+GIT_TRACE="$TRASH_DIRECTORY/trace.out"gitfetch--recurse-submodules-j22>../actual.err)&&test_must_be_emptyactual.out&&test_i18ncmpexpect.erractual.err&&
From: SZEDER Gábor <hidden> Date: 2018-02-23 23:40:44
't1510-repo-setup.sh' checks the stderr of nested function calls way
too many times, resulting in several failures when using '-x' tracing,
unless it's executed with a Bash version supporting BASH_XTRACEFD.
Maybe someday we will clear up this test script, but until then mark
it as 'test_untraceable'.
After this change
make GIT_TEST_OPTS='-x --verbose-log' test
finally fully passes without setting TEST_SHELL_PATH to Bash.
Signed-off-by: SZEDER Gábor <redacted>
---
t/t1510-repo-setup.sh | 4 ++++
1 file changed, 4 insertions(+)
@@ -39,6 +39,10 @@ A few rules for repo setup:11.Whenuser'scwdisoutsideworktree,cwdremainsunchanged,prefixisNULL."++# This test heavily relies on the standard error of nested function calls.+test_untraceable=UnfortunatelyYes+ ../test-lib.shhere=$(pwd)
From: Eric Sunshine <hidden> Date: 2018-02-24 08:04:26
On Fri, Feb 23, 2018 at 6:39 PM, SZEDER Gábor [off-list ref] wrote:
The two test checking 'git mmerge-recursive' in an empty worktree in
s/mmerge/merge/, I guess.
't3030-merge-recursive.sh' fail when the test script is run with '-x'
tracing (and using a shell other than a Bash version supporting
BASH_XTRACEFD). The reason for those failures is that the tests check
the emptiness of a subshell's stderr, which includes the trace of
commands executed in that subshell as well, throwing off the emptiness
check.
Note that both subshells execute four git commands each, meaning that
checking the emptiness of the whole subshell implicitly ensures that
not only 'git merge-recursive' but none of the other three commands
outputs anything to their stderr. Note also that if one of those
commands were to output anything on its stderr, then the current
combined check would not tell us which one of those four commands the
unexpected output came from.
Save the stderr of those four commands only instead of the whole
subshell, so it remains free from tracing output, and save and check
them individually, so they will show us from which command the
unexpected output came from.
After this change t3030 passes with '-x', even when running with
/bin/sh.
Signed-off-by: SZEDER Gábor <redacted>
From: SZEDER Gábor <hidden> Date: 2018-02-24 12:19:15
On Sat, Feb 24, 2018 at 12:39 AM, SZEDER Gábor [off-list ref] wrote:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
From: SZEDER Gábor <hidden> Date: 2018-02-25 13:40:34
Running a test script with '-x' turns on 'set -x' tracing, the output
of which is normally sent to stderr. This causes a lot of
test failures, because many tests redirect and verify the stderr
of shell functions, most frequently that of 'test_must_fail'.
These issues were worked around somewhat in d88785e424 (test-lib: set
BASH_XTRACEFD automatically, 2016-05-11), so at least we could
reliably run tests with '-x' tracing under a Bash version supporting
BASH_XTRACEFD, i.e. v4.1 and later.
Futhermore, redirecting the stderr of test helper functions like
'test_must_fail' or 'test_expect_code' is the cause of a different
issue as well. If these functions detect something unexpected, they
will write their error messages intended to the user to thier stderr.
However, if their stderr is redirected in order to save and verify the
stderr of the tested git command invoked in the function, then the
function's error messages will be redirected as well. Consequently,
those messages won't reach the user, making the test's verbose output
less useful.
This patch makes it safe to redirect and verify the stderr of those
test helper functions which are meant to run the tested command given
as argument, even when running tests with '-x' and /bin/sh. This is
achieved through a couple of file descriptor redirections:
- Duplicate stderr of the tested command executed in the test helper
function from the function's fd 7 (see next point), to ensure that
the tested command's error messages go to a different fd than the
'-x' trace of the commands executed in the function or the
function's error messages.
- Duplicate the test helper function's fd 7 from the function's
original stderr, meaning that, after taking a detour through fd 7,
the error messages of the tested command do end up on the
function's original stderr.
- Duplicate stderr of the test helper function from fd 4, i.e. the
fd connected to the test script's original stderr and the fd used
for BASH_XTRACEFD. This ensures that the '-x' trace of the
commands executed in the function
- doesn't go to the function's original stderr, so it won't mess
with callers who want to save and verify the tested command's
stderr.
- does go to the same fd independently from the shell running
the test script, be it /bin/sh, an older Bash without
BASH_XTRACEFD, or a more recent Bash already supporting
BASH_XTRACEFD.
Furthermore, this also makes sure that the function's error
messages go to this fd 4, meaning that the user will be able to
see them even if the function's stderr is redirected in the test.
- Specify the latter two redirections above in the test helper
function's definition, so they are performed every time the
function is invoked, without the need to modify the callsites of
the function.
Perform these redirections in those test helper functions which can be
expected to have their stderr redirected, i.e. in the functions
'test_must_fail', 'test_might_fail', 'test_expect_code', 'test_env',
'nongit', 'test_terminal' and 'perl'. Note that 'test_might_fail',
'test_env', and 'nongit' are not involved in any test failures when
running tests with '-x' and /bin/sh.
The other test helper functions are left unchanged, because they
either don't run commands specified as their arguments, or redirecting
their stderr wouldn't make sense, or both.
With this change the number of failures when running the test suite
with '-x' tracing and /bin/sh goes down from 340 failed tests in 43
test scripts to 22 failed tests in 6 scripts (or 23 in 7, if the
system (OSX) uses an older Bash version without BASH_XTRACEFD to run
't9903-bash-prompt.sh').
Signed-off-by: SZEDER Gábor <redacted>
---
Changes:
- Duplicate from/to fd 7 instead of fd 9 in 'test_terminal'.
- Talk about the issue that redirecting stderr of test helper
functions affect their error messages as well, and how this patch
resolves that issue as well.
t/lib-terminal.sh | 4 ++--
t/test-lib-functions.sh | 24 ++++++++++++------------
2 files changed, 14 insertions(+), 14 deletions(-)
@@ -644,7 +644,7 @@ test_must_fail () {return1fireturn0-}+}7>&22>&4# Similar to test_must_fail, but tolerates success, too. This is# meant to be used in contexts like:
@@ -658,8 +658,8 @@ test_must_fail () {# because we want to notice if it fails due to segv. test_might_fail(){-test_must_failok=success"$@"-}+test_must_failok=success"$@"2>&7+}7>&22>&4# Similar to test_must_fail and test_might_fail, but check that a# given command exited with a given exit code. Meant to be used as:
@@ -680,7 +680,7 @@ test_expect_code () {echo>&2"test_expect_code: command exited with $exit_code, we wanted $want_code$*"return1-}+}7>&22>&4# test_cmp is a helper function to compare actual and expected output.# You can use it like:
@@ -882,8 +882,8 @@ test_write_lines () {} perl(){-command"$PERL_PATH""$@"-}+command"$PERL_PATH""$@"2>&7+}7>&22>&4# Is the value one of the various ways to spell a boolean true/false? test_normalize_bool(){
@@ -1023,13 +1023,13 @@ test_env () {shift;;*)-"$@"+"$@"2>&7exit;;esacdone)-}+}7>&22>&4# Returns true if the numeric exit code in "$2" represents the expected signal# in "$1". Signals should be given numerically.
@@ -1071,9 +1071,9 @@ nongit () {GIT_CEILING_DIRECTORIES=$(pwd)&&exportGIT_CEILING_DIRECTORIES&&cdnon-repo&&-"$@"+"$@"2>&7)-}+}7>&22>&4# convert stdin to pktline representation; note that empty input becomes an# empty packet, not a flush packet (for that you can just print 0000 yourself).
From: SZEDER Gábor <hidden> Date: 2018-03-02 15:32:23
On Sat, Feb 24, 2018 at 12:39 AM, SZEDER Gábor [off-list ref] wrote:
This patch series makes '-x' tracing of tests work reliably even when
running them with /bin/sh, and setting TEST_SHELL_PATH=bash will be
unnecessary.
make GIT_TEST_OPTS='-x --verbose-log' test
passes on my setup and on all Travis CI build jobs (though neither me
nor Travis CI run all tests, e.g. CVS).
I installed 'cvs' and whatnot to run t94* and t96* tests, and sure
enough, 5 tests in 2 test scripts fail with '-x' tracing and /bin/sh.
I think I will be able to get around to send v2 during the weekend.
From: Jeff King <hidden> Date: 2018-03-03 07:13:06
On Sat, Feb 24, 2018 at 12:39:40AM +0100, SZEDER Gábor wrote:
The first patch is the most important: with a couple of well-placed file
descriptor redirections it ensures that the stderr of the test helper
functions running git commands only contain the stderr of the tested
command, thereby resolving over 90% of the failures resulting from
running the test suite with '-x' and /bin/sh.
I dunno. It seems like this requires a lot of caveats for people using
subshells and shell functions, and I suspect it's going to be an
on-going maintenance burden.
That said, I'm not opposed if you want to do the work to try to get the
whole test-suite clean, and we can see how it goes from there. It
shouldn't be hurting anything, I don't think, aside from some
mysterious-looking redirects (but your commit messages seem to explain
it, so anybody can dig).
Does it make descriptor 7 magical, and something that scripts should
avoid touching? That would mean we have 2 magical descriptors now.
-Peff
From: SZEDER Gábor <hidden> Date: 2018-03-05 21:18:41
On Sat, Mar 3, 2018 at 8:12 AM, Jeff King [off-list ref] wrote:
On Sat, Feb 24, 2018 at 12:39:40AM +0100, SZEDER Gábor wrote:
quoted
The first patch is the most important: with a couple of well-placed file
descriptor redirections it ensures that the stderr of the test helper
functions running git commands only contain the stderr of the tested
command, thereby resolving over 90% of the failures resulting from
running the test suite with '-x' and /bin/sh.
I dunno. It seems like this requires a lot of caveats for people using
subshells and shell functions, and I suspect it's going to be an
on-going maintenance burden.
After finally figuring out the redirections in the first patch, I was
quite surprised by how few failing tests remained. We only gathered 28
such tests over all these years; if it continues at this rate, that
probably won't be that much of a burden. And the second patch provides
an escape hatch, should it ever be needed.
The current situation, however, is a burden much more frequently,
because the idiosyncrasies of TEST_SHELL_PATH and/or '--verbose-log' pop
up whenever trying to run any test script with '-x' that has such a test
in it.
I think this is the right tradeoff.
That said, I'm not opposed if you want to do the work to try to get the
whole test-suite clean, and we can see how it goes from there. It
shouldn't be hurting anything, I don't think, aside from some
mysterious-looking redirects (but your commit messages seem to explain
it, so anybody can dig).
Does it make descriptor 7 magical, and something that scripts should
avoid touching? That would mean we have 2 magical descriptors now.
Tests can still use fd 7 as long as they don't intend to attach it
directly to that particular git command that is run inside one of these
test helper functions.
I settled on fd 7 because that fd is already used as stderr for the
'test_pause' and 'debug' helper functions and it isn't used in any of
our tests.