Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14368 > unrolled thread

Re: temp env allows variables that look like array subscripts

Started byGrisha Levit <grishalevit@gmail.com>
First post2018-07-19 15:02 -0400
Last post2018-07-19 15:02 -0400
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: temp env allows variables that look like array subscripts Grisha Levit <grishalevit@gmail.com> - 2018-07-19 15:02 -0400

#14368 — Re: temp env allows variables that look like array subscripts

FromGrisha Levit <grishalevit@gmail.com>
Date2018-07-19 15:02 -0400
SubjectRe: temp env allows variables that look like array subscripts
Message-ID<mailman.3840.1532026949.1292.bug-bash@gnu.org>
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.

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web