[Top][All Lists]

[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 <address@hidden> 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:address@hidden";
>   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: 

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

reply via email to

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