[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Indirect access to variables, including arrays (was Re: Compare 2 ar
From: |
Dan Douglas |
Subject: |
Re: Indirect access to variables, including arrays (was Re: Compare 2 arrays.) |
Date: |
Thu, 07 Jun 2012 04:27:38 -0500 |
User-agent: |
KMail/4.8.3 (Linux/3.4.1-pf+; KDE/4.8.3; x86_64; ; ) |
On Thursday, June 07, 2012 10:01:51 AM Pierre Gaston wrote:
> On Thu, Jun 7, 2012 at 6:07 AM, Linda Walsh <bash@tlinx.org> wrote:
> >(no I haven't made it space/bracket...whatever proof...just a bit
> > more work)
>
> It's not just "a bit more work", there are many workarounds but it's not
> really possible to make a really robust generic solution for assignment,
> and in the end it just not as simple and pretty as nameref.
>
> Fwiw here is a robust and simple solution for in_:
>
> _in () {
> local e t
> t="${2:?}[@]";
> for e in "${!t}"; do [[ $1 = "$e" ]] && return 0;done
> return 1;
> }
>
Not robust due to the name conflicts with "e" or "t". There's also no good way
to generate a list of locals without parsing "local" output (i'd rather live
with the conflicts). I usually store indirect references in the positional
parameters for that reason. Proper encapsulation is impossible.
Also, the standard behavior of ${var:?} is nearly useless unless you want to
either create fatal errors or put the whole function into a subshell. I wish
there were a way to modify that expansion to something nonstandard but useful.
For associative arrays (where a null parameter is the only invalid key), the
best solution is to explicitly check for null parameters and bail out of the
function. There's no convenient way to do that other than looping.
I used a convoluted solution in this "multidimensional array" example:
http://wiki.bash-hackers.org/syntax/arrays#indirection
I'm not very happy with it and will probably change the ${x+${y[z]+...}}
hieroglyphics to something readable as soon as I can think of whatever sucks
the least.
Granted, these are atypical issues. I care about this more than most due to
Gentoo being stuck with Bash and eclasses being among the few valid reasons to
care about large safe extensible libraries written for a shell.
--
Dan Douglas