On Thursday, June 07, 2012 10:01:51 AM Pierre Gaston wrote: > On Thu, Jun 7, 2012 at 6:07 AM, Linda Walsh <b...@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