Re: temp env allows variables that look like array subscripts

[Grisha Levit]

On Wed, Jul 18, 2018 at 11:01 AM Chet Ramey <chet.ramey@case.edu> wrote:
> The question is what to do with them:
>
> 1. Reject them as invalid environment variable names.
>
> 2. Accept them as if they were valid assignment statements and create an
>    array variable, rejecting the second assignment because it uses an
>    invalid subscript, even though you can't export environment variables.
>
> 3. Create variables with the names as given, and just put them in the
>    environment of commands invoked by `f', under the principle that POSIX
>    says "applications shall be tolerant of such names [in the
>    environment]f." Of course, that doesn't mean applications have to put
>    garbage into the environment.

I would vote for (1) unless either:

(a) bash supports the rest of array-related assignment syntax in the temporary
environment, in which case (2) sounds better. i.e. it seems like it would be
surprising for `a[0]=X declare -p a' and `a=(X) declare -p a' to produce
different results, with the former creating an array and the latter a string.
or
(b) bash accepts other valid-as-environment-but-not-as-shell-variable names
in the temporary environment, in which case (3) sounds better. i.e. `a[0]'
and `a@0' are both valid environment variable names but neither are valid bash
variable names. It seems surprising that the former would be passed on to
commands but the latter rejected by the parser.