bug-bash
[Top][All Lists]
Advanced

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

Re: indirect variable behavior breakage


From: Chet Ramey
Subject: Re: indirect variable behavior breakage
Date: Fri, 9 Mar 2018 11:29:35 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 3/7/18 3:20 PM, christopher barry wrote:
> On Wed, 7 Mar 2018 11:45:13 -0500
> christopher barry <cbarry@rajant.com> wrote:
> 
> ===8<---snip
> 
>>
>> I am in fact using this method with associative arrays.
>>
>> I have a default hash that is full of default values for a particular
>> generic type of thing. Variations of this thing use many of the
>> defaults, but also set some values uniquely. I could simply duplicate
>> this hash everywhere, and edit the differences, but then changing
>> any defaults would require a change everywhere.
>>
>> As an alternative, I created a template hash that all non-default
>> things start out with.
>>
>> this template hash has all of it's values pointing to
>> "default_hash[somekey]"
>>
>> new things that need to change their specific values simply override
>> that and put in their string.
>>
>> Now, changes to actual values in default_hash are seen everywhere they
>> are not overridden locally by the specific thing using it.
>>
>> so reading a hash value may be an indirect pointer to the default_hash
>> or an overridden value set by the specific thing using the hash.
>>
>> ivar solves this nicely.
>>
>>
>> But to get back on point, the bug in bash was nasty, and it's
>> fantastic that it's fixed now, but throwing an error now, rather than
>> simply returning 1 with no data is a bit like throwing the baby out
>> with the bathwater.
>>
>>
>>  -C
> 
> Chet,
> 
> Does modifying this current behavior sound like anything you would be
> willing to entertain?

I think that throwing an error when the value of a variable used for
indirection would not be accepted as valid (and throw an error) when
used directly is the right thing to do, and I will leave it as the default
behavior.

I'm open to suggestions about how to allow alternate behavior: a shell
option, something controlled by the shell compatibility level, something
else? It seems like you're really interested in learning whether a
particular string is a valid shell variable and doing something based on
the result. You could check that directly -- the pattern to describe a
shell variable isn't that hard to write -- but I get the sense that you'd
rather not take the extra step.

Chet

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



reply via email to

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