From: Jeff King <peff@peff.net>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Junio C Hamano <gitster@pobox.com>,
Adam Spiers <git@adamspiers.org>,
git mailing list <git@vger.kernel.org>
Subject: Re: $PATH pollution and t9902-completion.sh
Date: Thu, 20 Dec 2012 16:04:47 -0500 [thread overview]
Message-ID: <20121220210447.GA32032@sigill.intra.peff.net> (raw)
In-Reply-To: <50D37AB2.1040508@web.de>
On Thu, Dec 20, 2012 at 09:53:06PM +0100, Torsten Bögershausen wrote:
> (Good to learn about the comm command, thanks )
> What do we think about this:
>
>
> diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
> index 3cd53f8..82eeba7 100755
> --- a/t/t9902-completion.sh
> +++ b/t/t9902-completion.sh
> @@ -62,12 +62,16 @@ test_completion ()
> {
> if test $# -gt 1
> then
> - printf '%s\n' "$2" >expected
> + printf '%s\n' "$2" | sort >expected.sorted
> else
> - sed -e 's/Z$//' >expected
> + sed -e 's/Z$//' | sort >expected.sorted
> fi &&
> run_completion "$1" &&
> - test_cmp expected out
> + sort <out >actual.sorted &&
> + >empty &&
> + comm -23 expected.sorted actual.sorted >actual &&
> + test_cmp empty actual &&
> + rm empty actual
I like test_* helpers that tell you what happened on error, but this
output will be kind of a weird diff (it is a diff showing things you
expected to have but did not get as additions, and no mention of things
you expected and got).
The output is human readable, so I think it is perfectly OK to print a
message about what is going on (we do this in test_expect_code, for
example). Something like:
test_fully_contains() {
sort "$1" >expect.sorted &&
sort "$2" >actual.sorted &&
comm -23 expect.sorted actual.sorted >missing
test -f missing -a ! -s missing &&
rm -f expect.sorted actual.sorted missing &&
return 0
{
echo "test_fully_contains: some lines were missing"
echo "expected:"
sed 's/^/ /' <"$1"
echo "actual:"
sed 's/^/ /' <"$2"
echo "missing:"
sed 's/^/ /' <missing
} >&2
return 1
}
Though come to think of it, just showing the diff between expect.sorted
and actual.sorted would probably be enough. It would show the missing
elements as deletions, the found elements as common lines, and the
"extra" elements as additions (which are not an error, but when you are
debugging, might be useful to know about).
-Peff
prev parent reply other threads:[~2012-12-20 21:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-17 1:05 $PATH pollution and t9902-completion.sh Adam Spiers
2012-12-20 14:55 ` Jeff King
2012-12-20 15:13 ` Adam Spiers
2012-12-20 17:25 ` Torsten Bögershausen
2012-12-20 18:36 ` Junio C Hamano
2012-12-20 19:55 ` Junio C Hamano
2012-12-20 20:01 ` Jeff King
2012-12-20 20:53 ` Torsten Bögershausen
2012-12-20 21:02 ` Junio C Hamano
2012-12-20 21:04 ` Jeff King [this message]
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=20121220210447.GA32032@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@adamspiers.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tboegi@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).