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

Re: [PATCH v2] Fix false positives in t3404 due to SHELL=/bin/false

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 4, 2011, 23:39 UTC
Message-ID
<7vmxngdys8.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20110104225826.GA2122@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 29 quoted lines
> Matthieu Moy wrote:
>> "Vallon, Justin" <Justin.Vallon@deshaw.com> writes:
>
>>> --- a/t/t3404-rebase-interactive.sh
>>> +++ b/t/t3404-rebase-interactive.sh
>>> @@ -71,8 +71,9 @@ test_expect_success 'setup' '
>>>  # "exec" commands are ran with the user shell by default, but this may
>>>  # be non-POSIX. For example, if SHELL=zsh then ">file" doesn't work
>>>  # to create a file. Unseting SHELL avoids such non-portable behavior
>>> -# in tests.
>>> +# in tests. It must be exported for it to take effect where needed.
>>>  SHELL=
>>> +export SHELL
>>
>> (my bad, I wrote this SHELL= without exporting it. Since bash
>> re-exports already exported variables when they are assigned, and my
>> /bin/sh points to bash, I didn't notice)
>
> Isn't that how export works in all Bourne-style shells?  For example:
>
> 	$ env var=outside dash -c '
> 		var=inside;
> 		dash -c "echo \$var"
> 	  '
> 	inside
> 	$
>
> Maybe in the failing case SHELL was not exported but just set to
> /bin/false in .bashrc or similar?
Thanks, you saved me some time responding ;-)

Matthieu's diagnosis is only half correct in that bash is why he didn't notice the problem, but if in this sequence

	var=foo
        export var
        var=bar
        some-command

some-command does not see "bar" as the value of environment variable "var", your shell is not POSIX (there is no such thing as "re-exporting").

Either a variable is marked with the export attribute, in which case the processes spawned from the shell sees the value of the then-current shell variable in their environments, or they don't for shell variables that are not marked with the export attribute.

The real reason the problem went unnoticed was because bash automatially marks SHELL with the export attribute.

Because POSIX shells are required to mark variables they inherit from the environment with the export attribute, your tests will run with SHELL exported to the environment if your usual shell is bash (i.e. SHELL is already exported to processes it spawns), even if you use another POSIX shell to run your git and tests. That makes the issue doubly harder to notice.

Previous: Jonathan NiederNext: Vallon, Justin
Message 9 of 11 in “Fix false positives in t3404 due to SHELL=/bin/false”
  1. Fix false positives in t3404 due to SHELL=/bin/falseRobin H. Johnson, Dec 27, 2010
  2. Junio C HamanoDec 27, 2010
  3. Fix false positives in t3404 due to SHELL=/bin/falseRobin H. Johnson, Dec 27, 2010
  4. Junio C HamanoDec 28, 2010
  5. Vallon, JustinJan 4, 2011
  6. Robin H. JohnsonJan 4, 2011
  7. Matthieu MoyJan 4, 2011
  8. Jonathan NiederJan 4, 2011
  9. Junio C HamanoJan 4, 2011
  10. Vallon, JustinJan 5, 2011
  11. Junio C HamanoJan 5, 2011

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.