From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: John Keeping <john@keeping.me.uk>,
git@vger.kernel.org, Eric Sunshine <sunshine@sunshineco.com>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [RFC] test_when_finished in subshells
Date: Sat, 5 Sep 2015 04:54:30 -0400 [thread overview]
Message-ID: <20150905085429.GB25039@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqfv2uf2kc.fsf@gitster.mtv.corp.google.com>
On Fri, Sep 04, 2015 at 11:43:15AM -0700, Junio C Hamano wrote:
> > t7800 (in its final test) calls test_config in a subshell which has cd'd
> > into a submodule.
> >
> > Is this something worth worrying about, or is it sufficiently rare that
> > we can live with the current behaviour?
>
> Fixing the instances you found is good, obviously ;-). Thanks for
> working on this.
>
> Even though the proposed detection is BASH-ism, I think it would not
> hurt other shells (they obviously do not help you catch bugs, but
> they would not misbehave as long as you make sure BASH_SUBSHELL is
> either unset or set to 0 at the beginning of the test), and the only
> impact to them would be a invocation of (often built-in) 'test'
> utility, whose performance impact should be miniscule.
>
> I'll wait for opinion from others, of course.
I like it. In general I'm in favor of any lint-like fixes (whether for
the tests or the C code itself) as long as:
1. they don't create false positive noise
2. they don't require extra effort at each call-site
3. they don't have a performance impact
And I think this passes all three. Of course it would be nice if the new
check ran on all shells, but even this seems like a strict improvement.
And I couldn't come up with anything better. I thought we might be able
to use a canary trap, like this:
trap canary QUIT
echo outside
trap
echo inside
(trap)
Because traps are reset inside a subshell, the first "trap" without
arguments should print a string with "canary" in it, and the second
should print nothing.
Except that it isn't remotely how it works in practice. :) Bash leaves
the trap in place inside the subshell. And while dash does the right
thing, any attempt to actually _look_ at the output will put us in a
subshell. So:
case "$(trap)" in
*canary*) ... not in a subshell ...
*) ... in a subshell ...
esac
doesn't work; the trap report inside backticks is always empty (despite
there being an explicit example in the POSIX manpage for trap of using
$(trap) to get the value for a later eval).
It looks like if we use the EXIT trap rather than a signal, bash _does_
do the right thing (which kind of makes sense, I guess). So rather than
a custom canary, we could use our regular EXIT handler as the canary.
But I couldn't find a way to work around dash's issue.
Looks like there was even some discussion in 2010:
http://www.spinics.net/lists/dash/msg00331.html
but my dash 0.5.7 remains broken. Oh, well.
-Peff
next prev parent reply other threads:[~2015-09-05 8:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 17:58 [RFC] test_when_finished in subshells John Keeping
2015-09-04 18:43 ` Junio C Hamano
2015-09-05 8:54 ` Jeff King [this message]
2015-09-05 13:12 ` [PATCH 0/5] disallow " John Keeping
2015-09-05 13:12 ` [PATCH 1/5] t7610: don't use test_config in a subshell John Keeping
2015-09-05 13:12 ` [PATCH 2/5] t5801: don't use test_when_finished " John Keeping
2015-09-05 13:12 ` [PATCH 3/5] test-lib-functions: support "test_config -C <dir> ..." John Keeping
2015-09-05 13:12 ` [PATCH 4/5] t7800: don't use test_config in a subshell John Keeping
2015-09-05 13:12 ` [PATCH 5/5] test-lib-functions: detect test_when_finished in subshell John Keeping
2015-09-06 9:51 ` Eric Sunshine
2015-09-06 11:46 ` John Keeping
2015-09-06 16:22 ` Eric Sunshine
2015-09-05 17:36 ` [PATCH 0/5] disallow test_when_finished in subshells Junio C Hamano
2015-09-05 17:57 ` John Keeping
2015-09-05 20:17 ` 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=20150905085429.GB25039@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
--cc=jrnieder@gmail.com \
--cc=sunshine@sunshineco.com \
/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).