bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: temp env allows variables that look like array subscripts


From: Chet Ramey
Subject: Re: temp env allows variables that look like array subscripts
Date: Wed, 18 Jul 2018 11:00:58 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

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 address@hidden f
> declare -x var[0]="X"
> declare -x address@hidden"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    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]