Re: readline expansion: 'cp $v/<TAB>' -> 'cp \$v/' (no expansion) - why?

[Jason Vas Dias]

On Sun, Jul 8, 2012 at 5:50 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 7/7/12 11:39 AM, Jason Vas Dias wrote:
>
>> Next Question :
>>   - any plans to allow us to export array or associative store
>> variables ? ie. represent them in *environ passed to programs
>>      with an integration with glibc  "getenv()"  to support this ?
>
> 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 ?

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 ?
 And is there any way for the current bash to support exported
variables whose names contain '.' ?
Thanks & Regards , Jason



> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>
>