On Wed, 7 Mar 2018 11:09:10 -0500
Greg Wooledge <wool...@eeg.ccf.org> wrote:
> On Wed, Mar 07, 2018 at 10:54:22AM -0500, christopher barry wrote:
> > So yes 'ivar -3' is very, very bad indeed, and was a nasty bug, and
> > I absolutely agree that making sure the string is a validly
> > formatted var name before attempting to evaluate it is the right
> > approach.
> > My only request is for bash to not throw an error when it realizes
> > it's invalid. Returning 1 and no data seems like a reasonable
> > response that fixes the prior bug, but will not break this
> > use-case.
> Just out of curiosity, what *is* this use case, and why are you not
> using an associative array?
> It seems like you are trying to map strings of gibberish to nothing,
> and strings of non-gibberish to values. An associative array does
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
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