Junio C Hamano <[email protected]> writes:
> That leaves us to something along this line...
>
>> (3) Add a method "test_must_fail_or_die" to
>> "test-lib-functions.sh". This method accepts exit codes 129<x<192,
>> too. Use the new method in t5516.
>
> ... but I have to wonder if 129<x<192 is loosening too much, given
> that the only error we expect, other than the orderly shutdown, is
> reception of sigpipe.
So, how about doing something like this as a starter. All of the
object transport codepath share "we may notice that the other end
disconnected, or that the other end explicitly told us it found an
error, and die, or the other end may have died, perhaps after giving
a human-readable error message, and we end up dying when we try to
tell them more with SIGPIPE", and that by itself is not a bug in the
real life---we will exit with non-zero status and that is a sign
enough for the user to know that the command has failed.
t/test-lib-functions.sh | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 6dffb8b..b1f950d 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -579,6 +579,9 @@ test_must_fail () {
if test $exit_code = 0; then
echo >&2 "test_must_fail: command succeeded: $*"
return 1
+ elif test $exit_code -eq 141; then
+ echo >&2 "test_must_fail: died with sigpipe: $*"
+ return 0
elif test $exit_code -gt 129 && test $exit_code -le 192; then
echo >&2 "test_must_fail: died by signal: $*"
return 1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
