Re: [PATCH] test-lib: stricter unzip(1) check
From: Junio C Hamano <hidden>
Date: 2016-07-18 18:20:29
Johannes Schindelin [off-list ref] writes:
Hrm. That sounds a little magical, and fragile, to me. What if the next person's unzip returns 0 and *still* cannot handle -a?
That is a very sensible line of thought.
I'd rather do something like
... but the patch presented as an alternative does not seem to follow that line of thought. After reading that sensible line of thought I would have expected to see an auto-detection of the path and support for features we care about. Stepping back a bit, why do we even care if "unzip -a" works on "../$zipfile" and converts things correctly in that check_zip() test in t5003 in the first place? It looks more like a test on "unzip" than making sure we correctly generate a zip archive to me...
quoted hunk
-- snipsnap --diff --git a/t/test-lib.sh b/t/test-lib.sh index 0055ebb..5b9521e 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh@@ -929,7 +929,8 @@ yes () { } # Fix some commands on Windows -case $(uname -s) in +uname_s=$(uname -s) +case $uname_s in *MINGW*) # Windows has its own (incompatible) sort and find sort () {@@ -1100,6 +1101,7 @@ test_lazy_prereq SANITY ' return $status ' +test FreeBSD != $uname_s || GIT_UNZIP=${GIT_UNZIP:-/usr/local/bin/unzip} GIT_UNZIP=${GIT_UNZIP:-unzip} test_lazy_prereq UNZIP ' "$GIT_UNZIP" -v