From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Emily Shaffer <emilyshaffer@google.com>,
Jonathan Tan <jonathantanmy@google.com>,
git@vger.kernel.org
Subject: Re: Git in Outreachy December 2019?
Date: Wed, 9 Oct 2019 19:25:51 +0200 [thread overview]
Message-ID: <20191009172551.GI29845@szeder.dev> (raw)
In-Reply-To: <20190927221857.GB31237@sigill.intra.peff.net>
On Fri, Sep 27, 2019 at 06:18:58PM -0400, Jeff King wrote:
> On Thu, Sep 26, 2019 at 11:44:48PM +0200, SZEDER Gábor wrote:
>
> > All that was over a year and a half ago, and these limitations weren't
> > a maintenance burden at all so far, and nobody needed that escape
> > hatch.
> I'm actually surprised we haven't run into it more. We have some custom
> test scripts in our fork of Git at GitHub. We usually just use
> TEST_SHELL_PATH=bash, but curious, I tried running with dash and "-x",
> and three of them failed.
I try to avoid using TEST_SHELL_PATH at all costs, it is far too keen
to not do what I naively expect.
> Probably they'd be easy enough to fix (and they're out of tree anyway),
> so I'm not really arguing against the escape hatch exactly. Mostly I'm
> just surprised that if I introduced 3 cases (out of probably a dozen
> scripts), I'm surprised that more contributors aren't accidentally doing
> so upstream.
I see it a bit differently. Over a decade we gathered about
twenty-something such tests cases: that's about two cases per year.
You added three such cases in about a year and a half: that's two
cases per year. The numbers add up perfectly, you singlehandedly took
care of everything ;)
Anyway, I did some more digging, and, unfortunately, it turned out
that Dscho is somewhat right. While the situation is not as bad as he
made it look like ("We need Bash!"), it's not as good as I thought it
is ("But it Just Works!!") either.
- Some shells do include file descriptor redirections in the trace
output, and it varies between implementations to which fd the
trace of the redirection goes.
- 'ksh/ksh93' and NetBSD's /bin/sh send the trace of
redirections to the "wrong" fd, in the sense that e.g. the
trace of commands invoked in 'test_must_fail' goes to the
function's standard error, and checking its stderr with
'test_cmp' would then fail.
(But 'ksh/ksh93' doesn't really matter, because they don't
support the 'local' keyword, so they fail a bunch of tests
even without '-x' anyway.)
I don't think we can do anything about these shells.
- 'mksh/lksh' send the trace of redirections to the "right" fd,
so they won't pollute the stderr of test helper functions.
And indeed the test suite passes when run with 'mksh' (well,
at least the subset of the test suite that I usually run).
- We do call 'test_have_prereq' from within test cases as well,
notably from the 'test_i18ngrep', 'test_i18ncmp' and
'test_ln_s_add' helper functions. In those cases all trace output
from 'test_have_prereq' is included in the test case's trace
output, which means that during the first invocation:
- there is lots of distracting and confusing trace output, as
the script evaluating the prereq is passed around to a bunch
of functions.
- after running the script evaluating the prereq 'test_eval_'
does indeed turn off tracing, so there will be no trace from
the remainder of that test case (except with 'mksh': while it
does run 'set +x' in 'test_eval_', that somehow doesn't turn
off tracing... I have no idea whether that's a bug or a
feature).
As far as 'test_i18ngrep' is concerned, which accounts for the
majority of 'test_have_prereq' invocations within test cases, I
don't understand why it uses 'test_have_prereq' in the first place
instead of checking the GIT_TEST_GETTEXT_POISON environment
variable; and 6cdccfce1e (i18n: make GETTEXT_POISON a runtime
option, 2018-11-08) doesn't give me any insight.
I recall that some months ago we discussed the idea of how to
disable trace output from within test helper functions; that would
help with this 'test_have_prereq' issue as well, at least in case
of the more "common" shells.
next prev parent reply other threads:[~2019-10-09 17:25 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-27 5:17 Git in Outreachy December 2019? Jeff King
2019-08-31 7:58 ` Christian Couder
2019-08-31 19:44 ` Olga Telezhnaya
2019-09-04 19:41 ` Jeff King
2019-09-05 7:24 ` Christian Couder
2019-09-05 19:39 ` Emily Shaffer
2019-09-06 11:55 ` Carlo Arenas
2019-09-07 6:39 ` Jeff King
2019-09-07 10:13 ` Carlo Arenas
2019-09-07 6:36 ` Jeff King
2019-09-08 14:56 ` Pratyush Yadav
2019-09-09 17:00 ` Jeff King
2019-09-23 18:07 ` SZEDER Gábor
2019-09-26 9:47 ` SZEDER Gábor
2019-09-26 19:32 ` Johannes Schindelin
2019-09-26 21:54 ` SZEDER Gábor
2019-09-26 11:42 ` Johannes Schindelin
2019-09-13 20:03 ` Jonathan Tan
2019-09-13 20:51 ` Jeff King
2019-09-16 18:42 ` Emily Shaffer
2019-09-16 21:33 ` Eric Wong
2019-09-16 21:44 ` SZEDER Gábor
2019-09-16 23:13 ` Jonathan Nieder
2019-09-17 0:59 ` Jeff King
2019-09-17 11:23 ` Johannes Schindelin
2019-09-17 12:02 ` SZEDER Gábor
2019-09-23 12:47 ` Johannes Schindelin
2019-09-23 16:58 ` SZEDER Gábor
2019-09-26 11:04 ` Johannes Schindelin
2019-09-26 13:28 ` SZEDER Gábor
2019-09-26 19:39 ` Johannes Schindelin
2019-09-26 21:44 ` SZEDER Gábor
2019-09-27 22:18 ` Jeff King
2019-10-09 17:25 ` SZEDER Gábor [this message]
2019-10-11 6:34 ` Jeff King
2019-09-23 18:19 ` Jeff King
2019-09-24 14:30 ` Johannes Schindelin
2019-09-17 15:10 ` Christian Couder
2019-09-23 12:50 ` Johannes Schindelin
2019-09-23 19:30 ` Jeff King
2019-09-23 18:07 ` Jeff King
2019-09-24 14:25 ` Johannes Schindelin
2019-09-24 15:33 ` Jeff King
2019-09-28 3:56 ` Junio C Hamano
2019-09-24 0:55 ` Eric Wong
2019-09-26 12:45 ` Johannes Schindelin
2019-09-30 8:55 ` Eric Wong
2019-09-28 4:01 ` Junio C Hamano
2019-09-20 17:04 ` Jonathan Tan
2019-09-21 1:47 ` Emily Shaffer
2019-09-23 14:23 ` Christian Couder
2019-09-23 19:40 ` Jeff King
2019-09-23 22:29 ` Philip Oakley
2019-10-22 21:16 ` Emily Shaffer
2019-09-23 11:49 ` Christian Couder
2019-09-23 17:58 ` Jonathan Tan
2019-09-23 19:27 ` Jeff King
2019-09-23 20:48 ` Jonathan Tan
2019-09-23 19:15 ` Jeff King
2019-09-23 20:38 ` Jonathan Tan
2019-09-23 21:28 ` Jeff King
2019-09-24 17:07 ` Jonathan Tan
2019-09-26 7:09 ` 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191009172551.GI29845@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
--cc=peff@peff.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).