diff mbox series

[1/2] t3701: avoid one-shot export for shell functions

Message ID 5536b336-5122-47fd-be57-42c299abe60c@gmail.com (mailing list archive)
State New, archived
Headers show
Series [1/2] t3701: avoid one-shot export for shell functions | expand

Commit Message

Rubén Justo July 22, 2024, 11:24 p.m. UTC
The common construct:

    VAR=VAL command args

it's a common way to define one-shot variables within the scope of
executing a "command".

However, when "command" is a function which in turn executes the
"command", the behavior varies depending on the shell:

 ** Bash 5.2.21 **

    $ f () { bash -c 'echo A=$A'; }
    $ A=1 f
    A=1

 ** dash 0.5.12-9 **

    $ f () { bash -c 'echo A=$A'; }
    $ A=1 f
    A=1

 ** dash 0.5.10.2-6 **

    $ f () { bash -c 'echo A=$A'; }
    $ A=1 f
    A=

One of our CI jobs on GitHub Actions uses Ubuntu 20.04 running dash
0.5.10.2-6, so we failed the test t3701:51;  the "git add -p" being
tested did not get our custom GIT_PAGER, which broke the test.

Work it around by explicitly exporting the variable in a subshell.

Signed-off-by: Rubén Justo <rjusto@gmail.com>
---
 t/t3701-add-interactive.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Comments

Junio C Hamano July 22, 2024, 11:44 p.m. UTC | #1
Rubén Justo <rjusto@gmail.com> writes:

> The common construct:
>
>     VAR=VAL command args
>
> it's a common way to define one-shot variables within the scope of
> executing a "command".

"it's a" -> "is a".
"define" -> "set and export".

> However, when "command" is a function which in turn executes the
> "command", the behavior varies depending on the shell:
>
>  ** Bash 5.2.21 **
>
>     $ f () { bash -c 'echo A=$A'; }
>     $ A=1 f
>     A=1
>
>  ** dash 0.5.12-9 **
>
>     $ f () { bash -c 'echo A=$A'; }
>     $ A=1 f
>     A=1
>
>  ** dash 0.5.10.2-6 **
>
>     $ f () { bash -c 'echo A=$A'; }
>     $ A=1 f
>     A=
>
> One of our CI jobs on GitHub Actions uses Ubuntu 20.04 running dash
> 0.5.10.2-6, so we failed the test t3701:51;  the "git add -p" being
> tested did not get our custom GIT_PAGER, which broke the test.
>
> Work it around by explicitly exporting the variable in a subshell.

Nicely described.

>
> Signed-off-by: Rubén Justo <rjusto@gmail.com>
> ---
>  t/t3701-add-interactive.sh | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index c60589cb94..1b8617e0c1 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -616,7 +616,11 @@ test_expect_success TTY 'P handles SIGPIPE when writing to pager' '
>  	test_when_finished "rm -f huge_file; git reset" &&
>  	printf "\n%2500000s" Y >huge_file &&
>  	git add -N huge_file &&
> -	test_write_lines P q | GIT_PAGER="head -n 1" test_terminal git add -p
> +	test_write_lines P q | (
> +		GIT_PAGER="head -n 1" &&
> +		export GIT_PAGER &&
> +		test_terminal git add -p
> +	)
>  '
>  
>  test_expect_success 'split hunk "add -p (edit)"' '
Junio C Hamano July 22, 2024, 11:57 p.m. UTC | #2
Junio C Hamano <gitster@pobox.com> writes:

> Rubén Justo <rjusto@gmail.com> writes:
>
>> The common construct:
>>
>>     VAR=VAL command args
>>
>> it's a common way to define one-shot variables within the scope of
>> executing a "command".
>
> "it's a" -> "is a".
> "define" -> "set and export".
>
>> However, when "command" is a function which in turn executes the
>> "command", the behavior varies depending on the shell:
>>
>>  ** Bash 5.2.21 **
>>
>>     $ f () { bash -c 'echo A=$A'; }
>>     $ A=1 f
>>     A=1
>>
>>  ** dash 0.5.12-9 **
>>
>>     $ f () { bash -c 'echo A=$A'; }
>>     $ A=1 f
>>     A=1
>>
>>  ** dash 0.5.10.2-6 **
>>
>>     $ f () { bash -c 'echo A=$A'; }
>>     $ A=1 f
>>     A=

Another thing.  Let's insert a paragraph perhaps like this here.

    Note that POSIX explicitly says the effect of this construct
    used on a shell function is unspecified.

>> One of our CI jobs on GitHub Actions uses Ubuntu 20.04 running dash
>> 0.5.10.2-6, so we failed the test t3701:51;  the "git add -p" being
>> tested did not get our custom GIT_PAGER, which broke the test.
>>
>> Work it around by explicitly exporting the variable in a subshell.

That way, we won't give a wrong impression that we can safely start
using the construct in future once dash 0.5.10.2-6 goes away.
diff mbox series

Patch

diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index c60589cb94..1b8617e0c1 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -616,7 +616,11 @@  test_expect_success TTY 'P handles SIGPIPE when writing to pager' '
 	test_when_finished "rm -f huge_file; git reset" &&
 	printf "\n%2500000s" Y >huge_file &&
 	git add -N huge_file &&
-	test_write_lines P q | GIT_PAGER="head -n 1" test_terminal git add -p
+	test_write_lines P q | (
+		GIT_PAGER="head -n 1" &&
+		export GIT_PAGER &&
+		test_terminal git add -p
+	)
 '
 
 test_expect_success 'split hunk "add -p (edit)"' '