Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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...
> -- 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
--
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