Re: test '-v' - associative vs. normal array discrepancy - a bug ?

[konsolebox]

On Fri, Nov 21, 2014 at 7:13 PM, Stephane Chazelas
<stephane.chazelas@gmail.com> wrote:
> Or use
>
> eval "arg=\${$1}"

Yes.

> Or:
>
> eval "arg=\"\${$1}\"" # for ${array[*]}

Yes if allowed.

> which has the  benifit to also work with $0, $-, $!, $$,
> ${array[4]} (but obviously not so well with $1, $?, $#, $arg...)
> and as Greg pointed out is not any  more dangerous than declare
> -n.

I'm not really minding much about declare -n and this could apply even with
eval but just to point out:

1) Passing special parameters for reference doesn't make sense to me for many
obvious reasons.  I don't think any function should allow that.

2) array[n] is a special form.  It probably could work well with simple
assignments and expansions but that would depend if the function would allow
it.

>> to it is valid since if the user can do "blackbox 'a[b=$(something_evil)]'",
>> then why would he not just run something_evil directly anyway.  If it's
>> anything other than that then it's probably the scripts being called or is
>> running the automation that should be questioned.
>
> Greg's point was that "declare -n" is not any less dangerous
> than using eval here.

And I was also just giving the idea about how it could also apply to
interactive sessions just in case it would also be questioned in that aspect.

To make things clear I haven't really been questioning how declare -n would
differ from indirect variable expansion or eval.  In fact, I don't even use it
(at least not really yet since it's new to 4.3).  And I'm also not clueless
about circular references.  Not only do I consider the possibility to declare
-n but I also the just saw error message when I was creating the version of
is_defined().  Despite that I thought that it wasn't worth mentioning in any of
of my replies since I thought that it was pretty obvious.  Naming conflicts
already happen in indirect expansion and eval way before declare -n was made a
feature.  And I'm arguing that creating shared library functions is correctly
possible even on versions of Bash that's earlier than 4.3.

Also, consider this thread where I was requesting a new alternative command for
eval when it comes to assigning value to referred variables:

http://osdir.com/ml/bug-bash-gnu/2013-04/msg00034.html

And also my reply:

On Thu, Apr 4, 2013 at 9:11 PM, konsolebox <konsolebox@gmail.com> wrote:
> On second thought I think we still need the function since for declare -n:
>
> ...
>
> b) Same risk is at hand if a variable name passed to the function is not
> valid thereby making the error "invalid variable name for name reference".
> So anyone could still abuse it.
>
> So adding a function like setvalue would still be a good thing for a general
> purpose.
(http://osdir.com/ml/bug-bash-gnu/2013-04/msg00047.html)

I actually might have been the first one to introduce the basic trouble of it:

On Fri, Apr 5, 2013 at 9:15 AM, konsolebox <konsolebox@gmail.com> wrote:
> The only thing left here is that we can't have error control like when we
> are to create generally shared library scripts e.g.:
>
> function lib_something {
>     declare -n VAR=$1 &>/devnull || { # error message is not suppressed
>         : can_t go here if referred variable's name is invalid
>         return 1 # or do other things like proper error messaging
>     }
>     VAR["XYZ.1324"]="Some Value." &>/dev/null || { # error message is not
> suppressed
>         : can_t go here if referred variable is not of associative array
> type
>         return 1 # or do other things like proper error messaging
>     }
> }
(http://osdir.com/ml/bug-bash-gnu/2013-04/msg00061.html)

So perhaps that would reconsider the opinion about my thoughts on this matter.


Cheers,
konsolebox


P.S.  I did say namerefs here but I was also referring to references that's
not only declared by declare -n.  I noticed this but thought I didn't need to
clarify it after all with all the examples and other statements I made the idea
should be implied already.  Just saying this just in case it had caused
wrong ideas.

> To add, it's not only by namerefs that a function can refer a variable.  The
> reference can also just stay in a positional parameter.