On 7/17/18 4:51 PM, Grisha Levit wrote:
> Usually, an assignment preceding a command that would create a
> variable with an invalid name is rejected and treated like a command
> name:
>
> $ 1=X :
> bash: 1=X: command not found
>
> But when the variable name looks (sort of) like an array subscript
> assignment, it is accepted and an oddly named variable is created:
>
> $ f() { declare -p ${!var*}; }; var[0]=X var[@]=Y f
> declare -x var[0]="X"
> declare -x var[@]="Y"
They're valid assignment statements, and would be marked as such if
the command weren't there (the test for whether or not the subscript
is invalid comes after parsing). 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.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
