git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/5] disallow test_when_finished in subshells

From
John Keeping <john@keeping.me.uk>
Date
Sep 5, 2015, 17:57 UTC
Message-ID
<20150905175756.GE27660@serenity.lan>
In-Reply-To
<CAPc5daUsd8KD77EfF-SBwwOKn0hNPvYXo8UmY-sHBg9S4vUQXg@mail.gmail.com>
On Sat, Sep 05, 2015 at 10:36:29AM -0700, Junio C Hamano wrote:
Show 21 quoted lines
> On Sat, Sep 5, 2015 at 6:12 AM, John Keeping <john@keeping.me.uk> wrote:
> >
> > I don't think it's worth trying to clear $BASH_SUBSHELL before the tests
> > start because to do so we have to reliably detect that we're not running
> > under Bash, and if we don't trust people not to set $BASH_SUBSHELL why
> > do we trust them not to set $BASH?
> 
> I am not worried about evil people who do funny things to deliberately break
> other people's arrangement. I am more worried about stupid people (e.g. those
> who export CDPATH).
> 
> In bash a stupid person may attempt to export BASH_SUBSHELL and then
> have a script that runs our test suite, setting SHELL_PATH to point at a
> non-bash while building Git and running the tests under a non-bash shell. I
> am hesitant to believe that we will know the variable will never leak through
> to the test via environment.
> 
> Isn't it just the matter of resetting the variable regardless of $BASH
> (and ignoring
> a possible refusal to do so under bash) at the beginning of the test, or do you
> really have to rely on the value of $BASH and do things differently?

Bash doesn't refuse to set it, it lets you update the value; I did think that it wouldn't update it if the user had overridden the value, but it looks like that was only because I had unset it first. It seems that the variable is magic (autoincrementing in subshells and can only be set to integer values) but if you unset it then it becomes a normal variable.

I'm wary of relying on that behaviour being unchanged across all versions of bash, so I'd prefer to avoid writing the variable if running under bash.

We do already have t/lib-bash.sh which has an optimization to avoid exec'ing bash if "$BASH" is set, which will break in the same way if someone exports BASH and then runs t9902 or t9903 under non-bash.

Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 15 in “[RFC] test_when_finished in subshells”
  1. John KeepingSep 4, 2015
  2. Junio C HamanoSep 4, 2015
  3. Jeff KingSep 5, 2015
  4. 0/5 disallow test_when_finished in subshellsJohn Keeping, Sep 5, 2015
  5. 1/5 t7610: don't use test_config in a subshellJohn Keeping, Sep 5, 2015
  6. 2/5 t5801: don't use test_when_finished in a subshellJohn Keeping, Sep 5, 2015
  7. 3/5 test-lib-functions: support "test_config -C <dir> ..."John Keeping, Sep 5, 2015
  8. 4/5 t7800: don't use test_config in a subshellJohn Keeping, Sep 5, 2015
  9. 5/5 test-lib-functions: detect test_when_finished in subshellJohn Keeping, Sep 5, 2015
  10. Eric SunshineSep 6, 2015
  11. John KeepingSep 6, 2015
  12. Eric SunshineSep 6, 2015
  13. Junio C HamanoSep 5, 2015
  14. John KeepingSep 5, 2015
  15. Junio C HamanoSep 5, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.