On 7/8/12 4:14 PM, Jason Vas Dias wrote:
>> There is already code -- commented out -- to export array variables in
>> a format that resembles a compound array assignment, and code -- still
>> commented out -- in bash to understand them. It's not enabled because
>> the chance for obscure collisions with similarly-formed environment
>> variables is non-negligible and doesn't have an elegant solution.
>>
>> Chet
>
> Aha ! Interesting - which source file ?
bash-4.2.29: variables.c:371; variables.c:3479.
> The way I'd do it (and do it with shells that do not understand
> indexed / associative arrays), is,
> for array "my_array" and member "index" having value "$item" :
> "Add" or "Set" an item:
> eval 'export my_array_'${item_deref}'_'${index}'='$item
> "Get" an item:
> eval '$my_array_'${item_deref}'_'${index}
> 'Remove' an item
> eval 'undef my_array_'${item_deref}'_'${index}'
> and I'd suggest having item_deref=('.' or '__' or '@') also known to
> glibc getenv() or a new getenv_x()
> function in glibc so that programs can use them . Any plans along
> these lines ?
No. I'm not sure it's a good idea to create large numbers of environment
variables for exported arrays with large numbers of elements. That can
slow exec() down and lead to weird errors if the ARG_MAX limit, which
includes the environment, is exceeded. The same space problem exists for
the (currently-disabled) bash mechanism, granted.
I'm also not particularly interested in glibc-only interfaces. That's one
of the reasons that I'd like a solution to this to require only bash and
be more-or-less agnostic to other programs that might scan the environment.
> And is there any way for the current bash to support exported
> variables whose names contain '.' ?
No. Bash-4.2 doesn't allow variables with characters outside the set
[_a-zA-Z][_a-zA-Z0-9]*. It will pass environment strings that aren't
valid variable names through to the programs it invokes.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU [email protected] http://cnswww.cns.cwru.edu/~chet/
