Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxx> writes:
> The only problematic platforms I test on are "NTFS/bash" on cygwin and MinGW.
> Since commit 2b843732 ("Suppress some bash redirection error messages",
> 26-08-2008), I have not noticed any complaints regarding this problem.
> What have I missed?
>
> Assuming we are not talking about errors like ENOSPC, EROFS etc., then the
> only command which would issue a complaint to stderr would be the line
> following the above snippet, thus:
>
> +cat 2>/dev/null >"$p1" "$p0"
>
> (note the stderr redirection).
As I am more worried about longer-term health of the codebase, what
the part you moved outside test_expect_* with this patch happens to
do _right now_ is of secondary importance, at least from my point of
view. The next patch that updates this scirpt may want to run more
involved commands that can fail in different ways.
Being able to rely on the protection test_expect_* gives us in the
set-up phase of the test has been very valuable (in addition to
making the result more readable) to us. Can we keep that property
in some way while also keeping the ability to skip the remainder of
the test script?
Observing that all well-written test scripts we have begin with this
boilerplate line:
test_expect_success setup '
I wouldn't mind introducing a new helper function test_setup that
behaves like test_expect_success but is meant to be used in the
first "set-up" phase of the tests in a test script. Perhaps we can
give its failure a meaning different than failures in other normal
tests (e.g. "even set-up fails, and the remainder of the test is N/A
here, hence abort the whole thing"), and do not count "test_setup"
as part of the test (i.e. do not increment $test_count and friends).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html