Re: [PATCH v3] CodingGuidelines: document a shell that "fails" "VAR=VAL shell_func"

[Eric Sunshine <sunshine@sunshineco.com>]

On Mon, Jul 22, 2024 at 8:05 PM Junio C Hamano <gitster@pobox.com> wrote:
> Over the years, we accumulated the community wisdom to avoid the
> common "one-short export" construct for shell functions, but seem to
> have lost on which exact platform it is known to fail.  Now during
> an investigation on a breakage for a recent topic, we found one
> example of failing shell.  Let's document that.
> [...]
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> @@ -204,6 +204,33 @@ For shell scripts specifically (not exhaustive):
> + - The common construct
> +
> +       VAR=VAL command args
> +
> +   to temporarily set and export environment variable VAR only while
> +   "command args" is running is handy, but this triggers an
> +   unspecified behaviour accoreding to POSIX when used for a command

s/accoreding/according/

> +   that is not an external command (like shell functions).  Indeed,
> +   some versions of dash (like 0.5.10.2-6 found on Ubuntu 20.04) and
> +   AT&T ksh do make a temporary assignment without exporting the
> +   variable, in such a case.  Do not use it for shell functions.  A
> +   common workaround is to do an explicit export in a subshell, like
> +   so:
> +
> +       (incorrect)
> +       VAR=VAL func args
> +
> +       (correct)
> +       (
> +               VAR=VAL &&
> +               export VAR &&
> +               func args
> +       )
> +
> +   but be careful that the effect "func" makes to the variables in the
> +   current shell will be lost across the subshell boundary.