Re: [PATCH] test-lib: stricter unzip(1) check

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2016, 18:20 UTC
Message-ID: <xmqqtwfmkduk.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1607181536540.3472@virtualbox>

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

Show 23 quoted lines

> -- 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