bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compare 2 arrays.


From: Dan Douglas
Subject: Re: Compare 2 arrays.
Date: Thu, 31 May 2012 03:28:44 +0000

On Wed, May 30, 2012 at 4:57 PM, Greg Wooledge <address@hidden> wrote:
>
> On Wed, May 30, 2012 at 10:14:42AM -0600, Bill Gradwohl wrote:
> > What say you Chet? Bug or feature? There is no middle ground.
>
> That's unrealistic.  There are plenty of things that occupy that middle
> ground -- unexpected program behaviors.  The programmer can never
> anticipate *every* input sequence that users will throw at the software,
> so some of them may cause surprises.

Since variable names treated as strings can cause execution of
arbitrary code in Bash, mixing them with user input isn't usually
possible anyway. However, that's irrelevant to whether this kind of
expansion is a bug.

> The danger of using unexpected program behaviors in your applications
> is that the behaviors may change without warning in a future version of
> the program.  The programmer may not even be aware that this behavior
> exists, let alone that people are using it.  A clean-up of the parser
> (or similar change) may make the behavior go away, or change.

That is true, but I don't think this particular thing is unexpected.
Hopefully it doesn't change unless it's replaced by something better,
because it's extremely useful.

> ...
> I added that on 2011-05-02 after Buglouse described it on IRC.  I'm fairly
> certain that EVERYONE else in the channel at the time was as surprised
> by it as I was.
>

I think they shouldn't have been surprised. Here it is described on
stackoverflow prior to that date:
http://stackoverflow.com/a/4017175/495451

I don't understand why you continue to consider this a possible bug.
The manual only has a couple sentences to say about indirect
expansion:

"If the first character of parameter is an exclamation point (!), a
level of variable indirection is introduced.    Bash uses the value of
the variable formed from the rest of parameter as the name of the
variable; this variable is then expanded and that value is used in the
rest of the substitution, rather than the value of parameter itself.
This is known as indirect expansion."

And Bash does exactly that. If indirect array expansion is a bug, then
it's a documentation bug, because it's implied by the manual amongst
other things. The question is whether or not values of the form
"arr[n]" are considered valid "parameters" or "variable names". IMO,
they are. "The value of the variable formed from the rest of the
parameter" must itself be a "variable name" in order for these
sentences to make sense. This is consistent with their usage in
several Bash builtins that accept "variable names" as arguments such
as "read", "unset", and "printf". I consider some of those which don't
as bugs, such as "[[ -v". IMO, this should be made consistent. But at
least I've tested "${!x}" extensively in complex situations and it
works as expected every time. It's also not that difficult to
understand.

Still, it's an advanced feature and probably just as well that it's obfuscated.



reply via email to

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