git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Thomas Rast <trast@student.ethz.ch>
Cc: "Jonathan Nieder" <jrnieder@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
	"Michael Haggerty" <mhagger@alum.mit.edu>
Subject: Re: tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13))
Date: Wed, 14 Dec 2011 18:07:13 -0500	[thread overview]
Message-ID: <20111214230713.GA13128@sigill.intra.peff.net> (raw)
In-Reply-To: <201112141717.15021.trast@student.ethz.ch>

On Wed, Dec 14, 2011 at 05:17:14PM +0100, Thomas Rast wrote:

> > I also find Jeff's patch [3] appealing.
> 
> Me too, though wonder whether feeding a file full of garbage wouldn't
> be better, so as to trip up commands that try to read only from a
> non-tty stdin.

Interesting idea. Instead of getting an immediate EOF from /dev/null,
they'll get some junk which they may or may not complain about. I played
around with this a bit, redirecting test stdin from a file with:

  This is a garbage file that will be connected to the stdin of each
  test.

(with the hope that when you see that in an error message, it will be
obvious what has happened).

It turns out that shortlog (the one bug of this type in the test suite)
doesn't care at all. It will happily chew on that garbage and behave
just the same as if it had been given /dev/null.

There is also the minor issue that if there are multiple invocations of
the input-chewing command, the first one will eat all of the input, and
subsequent ones will just get the equivalent of /dev/null anyway. I.e.:

  test_expect_success 'git shortlog $foo' ;# will eat all of our stdin
  test_expect_success 'git shortlog $bar' ;# sees immediate EOF

That may not matter, though, as you would hope for the first invocation
to complain, at which point you fix it, revealing the failures in later
tests (or if you're clever, noticing in the first place that they all
have the same bug).

You can make this somewhat more robust by redirecting stdin for
_test_eval (so each test gets a fresh descriptor to the garbage file).
However, that disallows redirecting a specific test's stdin in the test
script, like:

  test_expect_success 'some test' '
    cat >expect &&
    some_command >actual &&
    test_cmp expect actual
  ' <<\EOF
  the expected
  data
  EOF

This construct probably seems silly at first, but see how it is used in
t6006:

  test_format author %an%n%ae%n%ad%n%aD%n%at <<\EOF
  commit ...
  A U Thor
  author@example.com
  ... etc ...
  EOF

where test_format is a generic function that just gobbles stdin into the
"expect" file. As it turns out, test_format actually runs the "cat"
outside of the "test_expect_success", but quite often we put it inside.
So maybe it isn't worth caring about. You could also argue that the
whole thing should just be inside a test_expect_success.

-Peff

  parent reply	other threads:[~2011-12-14 23:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14  1:19 What's cooking in git.git (Dec 2011, #04; Tue, 13) Junio C Hamano
2011-12-14  7:09 ` tr/pty-all (Re: What's cooking in git.git (Dec 2011, #04; Tue, 13)) Jonathan Nieder
2011-12-14 16:17   ` Thomas Rast
2011-12-14 17:42     ` Junio C Hamano
2011-12-14 23:07     ` Jeff King [this message]
2011-12-14 23:21       ` Jeff King
2011-12-14 23:31         ` Jonathan Nieder
2011-12-15  0:25           ` Jeff King
2011-12-15  0:50             ` Jeff King
2011-12-15  3:23               ` Junio C Hamano
2011-12-15  6:55                 ` Jeff King
2011-12-15 18:19                   ` Junio C Hamano

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=20111214230713.GA13128@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=mhagger@alum.mit.edu \
    --cc=pclouds@gmail.com \
    --cc=trast@student.ethz.ch \
    /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).