Rubén Justo <rjusto@xxxxxxxxx> 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@xxxxxxxxx>
> ---
> 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)"' '
