From: Todd Zullinger <tmz@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH] test-lib: try harder to ensure a working jgit
Date: Tue, 14 May 2019 21:12:18 -0400 [thread overview]
Message-ID: <20190515011217.GN3654@pobox.com> (raw)
In-Reply-To: <20190514084534.GA9567@sigill.intra.peff.net>
Hi,
Jeff King wrote:
> On Tue, May 14, 2019 at 02:14:19AM +0000, brian m. carlson wrote:
>
>> On Mon, May 13, 2019 at 10:05:20PM -0400, Todd Zullinger wrote:
>>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>>> index 908ddb9c46..599fd70e14 100644
>>> --- a/t/test-lib.sh
>>> +++ b/t/test-lib.sh
>>> @@ -1522,7 +1522,7 @@ test_lazy_prereq NOT_ROOT '
>>> '
>>>
>>> test_lazy_prereq JGIT '
>>> - type jgit
>>> + jgit --version
>>> '
>>
>> I think this is an improvement, not only because of the reasons you
>> mentioned, but because we remove the use of "type", which is not
>> guaranteed to be present in a POSIX shell.
>
> Isn't it?
I wondered the same thing, but I know I am not nearly as
familiar with the POSIX rules as any of you.
> I have always treated it as the most-portable option for this
> (compared to, say, `which`). It is in POSIX as a utility (albeit marked
> with XSI), which even says (in APPLICATION USAGE):
>
> Since type must be aware of the contents of the current shell
> execution environment (such as the lists of commands, functions, and
> built-ins processed by hash), it is always provided as a shell regular
> built-in.
>
> All that said, I think Todd's patch makes perfect sense even without
> wanting to avoid "type".
Yeah, `which` surely isn't a portable option. I presumed
`type` must be fairly widely available since it was in the
test suite since you added it way back in 212f2ffbf0 ("t:
add basic bitmap functionality tests", 2013-12-21).
I usually make use of `command -p -v $foo` in scripts that
need to be portable across systems. But I don't have access
to many esoteric systems.
Based on Junio's follow-up, I think we can avoid adding
anything to the commit message about the use of `type` here.
That way no one will take it as a sign that we should remove
other uses of it just for conformance. (I will send a
follow-up with an update based on Jonathan and Ævar's
comments.)
Thanks to all of you.
--
Todd
next prev parent reply other threads:[~2019-05-15 1:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 2:05 [PATCH] test-lib: try harder to ensure a working jgit Todd Zullinger
2019-05-14 2:14 ` brian m. carlson
2019-05-14 8:45 ` Jeff King
2019-05-15 0:52 ` Junio C Hamano
2019-05-15 1:12 ` Todd Zullinger [this message]
2019-05-15 23:20 ` brian m. carlson
2019-05-14 2:32 ` Jonathan Nieder
2019-05-14 8:09 ` Ævar Arnfjörð Bjarmason
2019-05-15 1:18 ` Todd Zullinger
2019-05-15 2:13 ` Junio C Hamano
2019-05-15 1:36 ` [PATCH v2] " Todd Zullinger
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=20190515011217.GN3654@pobox.com \
--to=tmz@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.