On Fri, Nov 21, 2014 at 7:13 PM, Stephane Chazelas
<stephane.chaze...@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 <konsole...@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 <konsole...@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.
