git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Eric Wong <e@80x24.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"René Scharfe" <l.s.r@web.de>,
	git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] test-lib: stricter unzip(1) check
Date: Mon, 18 Jul 2016 07:04:05 -0600	[thread overview]
Message-ID: <20160718130405.GA19751@sigill.intra.peff.net> (raw)
In-Reply-To: <20160718064431.GA10819@starla>

On Mon, Jul 18, 2016 at 06:44:31AM +0000, Eric Wong wrote:

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

> 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

  reply	other threads:[~2016-07-18 13:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18  6:44 [PATCH] test-lib: stricter unzip(1) check Eric Wong
2016-07-18 13:04 ` Jeff King [this message]
2016-07-18 13:52   ` Johannes Schindelin
2016-07-18 18:20     ` Junio C Hamano
2016-07-18 18:56       ` Jeff King
2016-07-18 19:17         ` Junio C Hamano
2016-07-19 11:27       ` Johannes Schindelin
2016-07-19 17:26         ` Junio C Hamano
2016-07-18 19:43   ` Junio C Hamano
2016-07-18 20:03     ` Eric Wong
2016-07-18 20:19       ` Junio C Hamano
2016-07-18 21:19         ` Eric Wong
2016-07-18 21:27           ` Junio C Hamano
2016-07-18 23:41     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160718130405.GA19751@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=l.s.r@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).