Re: Changing the way bash expands associative array subscripts

[konsolebox]

On Fri, Apr 9, 2021 at 8:17 PM Greg Wooledge <greg@wooledge.org> wrote:
> How can you look at that code and call it anything other than a hack?
> It's a piece of pure desperation.  You can only READ the array, not write
> to it.  You can't do an index iteration, either -- only a value iteration.
> And you still have all the same name collision issues that you'd get
> with namerefs.  This makes it genuinely inferior to using a nameref to
> acheive the same goal:

It's pretty obvious that indirection is only limited to read-only mode
and values iteration, and is only worth using to refer passed
variables in versions of bash that don't have namerefs yet, but that
doesn't make it a hack as its usability is clear.  It may look
obnoxious or alien but still not a hack.  array[@] is a valid
subscript reference whether you like it or not.

> (Insert here all of the problems with name collisions, which are real,
> but you should already know them.)

There are solid ways to avoid name collisions.  One I mentioned to you
many years ago in
https://lists.gnu.org/archive/html/bug-bash/2014-11/msg00132.html.
Let me reiterate and simplify it here.

1) Functions that refer to variables should have all its local
variables prefixed with two underscores.

local -n __r=$1
local __a __b

2) No prefixed variable should  be passed to another function.  If
desperate, prefix the variable with the function's name along with the
two underscores.

function my_function {
    local my_function__a
    another_function my_function__a
}

This solution applies to namerefs, indirections and evil eval.
Keeping the passed references sane is up to the scripter.


-- 
konsolebox