[Top][All Lists]

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

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

From: Chet Ramey
Subject: Re: readline expansion: 'cp $v/<TAB>' -> 'cp \$v/' (no expansion) - why?
Date: Sun, 08 Jul 2012 19:56:32 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1

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.

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

reply via email to

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