git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jul 18, 2016, 13:04 UTC
Message-ID
<20160718130405.GA19751@sigill.intra.peff.net>
In-Reply-To
<20160718064431.GA10819@starla>
On Mon, Jul 18, 2016 at 06:44:31AM +0000, Eric Wong wrote:
Show 9 quoted lines
> On FreeBSD 10.3 (but presumably any FreeBSD 8+), /usr/bin/unzip
> exists, but is insufficient for t5003 due to its non-standard
> handling of the -a option[1].  This version of unzip exits
> with "1" when given the "-v" flag.
> 
> However, the common Info-ZIP version may be installed at
> /usr/local/bin/unzip (via "pkg install unzip") to pass t5003.
> This Info-ZIP version exits with "0" when given "-v",
> so limit the prereq to only versions which return 0 on "-v".

I guess I am cc'd because of f838ce5 (test-lib: factor out $GIT_UNZIP setup, 2013-03-10). But really this check for 127 dates all the way back to Johannes's 3a86f36 (t5000: skip ZIP tests if unzip was not found, 2007-06-06), and was just pulled along as it got refactored into a various incarnations of prerequisite by me and René.

It's possible that there is some version of unzip that does not like "-v" but otherwise is OK with our tests, but we would skip tests using this patch. Even with the FreeBSD version you mention, I'd expect you could run all of the tests except for the single "-a" test.

So I wonder if we could more directly test the two levels we care about:
  - do you appear to have a working "unzip" at all?
  - does your unzip support "-a"?

My Debian version of unzip (which is derived from Info-zip) seems to give return code 0 for just "unzip". So for the first check, we could possibly drop "-v"; we don't care about "-v", but just wanted some way to say "does unzip exist on the path?". Another option would just be checking whether "unzip" returns something besides 127 (so what we have now, minus "-v").

To test for "-a", I think we'd have to actually feed it a sample zip file, though. My unzip returns "10", which its manpage explains as "invalid command line options" (presumably because of the missing zipfile argument). But that seems like it probably isn't portable. And it's also what I might expect another unzip to return if it doesn't support "-a".

So while this patch does solve the immediate problem, I think it does so by overly skipping tests that we _could_ run.

If we do go with this patch, though:
Show 11 quoted lines
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 11201e9..938f788 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1103,7 +1103,7 @@ test_lazy_prereq SANITY '
>  GIT_UNZIP=${GIT_UNZIP:-unzip}
>  test_lazy_prereq UNZIP '
>  	"$GIT_UNZIP" -v
> -	test $? -ne 127
> +	test $? -eq 0
>  '

...you can simply drop the "test" line, as testing $? against 0 is essentially a noop. If it is 0, then test will return 0; if it is not, then test will return non-zero. You can just return the value directly instead.

-Peff
Previous: Eric WongNext: Johannes Schindelin
Message 2 of 14 in “test-lib: stricter unzip(1) check”
  1. test-lib: stricter unzip(1) checkEric Wong, Jul 18, 2016
  2. Jeff KingJul 18, 2016
  3. Johannes SchindelinJul 18, 2016
  4. Junio C HamanoJul 18, 2016
  5. Jeff KingJul 18, 2016
  6. Junio C HamanoJul 18, 2016
  7. Johannes SchindelinJul 19, 2016
  8. Junio C HamanoJul 19, 2016
  9. Junio C HamanoJul 18, 2016
  10. Eric WongJul 18, 2016
  11. Junio C HamanoJul 18, 2016
  12. Eric WongJul 18, 2016
  13. Junio C HamanoJul 18, 2016
  14. Jeff KingJul 18, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.