[Top][All Lists]

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

Re: Changing the way bash expands associative array subscripts

From: konsolebox
Subject: Re: Changing the way bash expands associative array subscripts
Date: Sat, 10 Apr 2021 01:40:29 +0800

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
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.


reply via email to

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