git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).