On Fri, Apr 9, 2021 at 8:17 PM Greg Wooledge <g...@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