bug-bash
[Top][All Lists]
Advanced

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

Re: bash 5.0 nested array subscript arithmetic expansion error


From: Dan Douglas
Subject: Re: bash 5.0 nested array subscript arithmetic expansion error
Date: Tue, 16 Oct 2018 14:10:56 +0000

On Mon, Aug 27, 2018 at 8:12 PM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 8/27/18 12:25 PM, Grisha Levit wrote:
> > This used to work:
> >
> > bash-4.4$ a=0
> > bash-4.4$ echo $(( a[a[0]] ))
> > 0
> > bash-4.4$ echo ${a[a[a[0]]]}
> > 0

Just curious, did you decide what to do with this?

> This is part of changes in bash-5.0 to avoid expanding array subscripts
> more than one time. After expanding the subscript once, you don't want
> to expand (or check) nested open and close brackets again -- how do you
> get literal brackets into an associative array key, for instance?

By treating associative arrays and ordinary arrays differently.
Associative arrays should be the easier one because any
unescaped/unquoted bracket that isn't part of an expansion is part of
the string.

Integrating arithmetic into the overall Bison/Flex-defined syntax
would be an idealist answer, I guess. Not an easy fix.

Or, have the arithmetic processor stop whenever it encounters var[,
Hand the remainder of the current command back to the shell parser or
length into the expression where the expansion begins to figure out
its extent. Return the length to the end of the expansion plus the
expanded string, seek ahead, resume.

Or, re-use the code already used in contexts processing expansions on
arbitrary strings, such as the argument to case..esac. Arithmetic
doesn't contain tokens that start expansions so there's no need for
the shell to understand it. Just find the unescaped $'s (and
backticks, ugh), expand them, and tell the math processor their
locations and value. Ignoring ] on expanded strings of course.

If it were a temporary bodge I'd say add a shopt option to disable
recursive subscript processing in the event someone depends upon weird
strings in associative arrays. It often isn't a requirement. Too bad
adding this would probably mean supporting it forever.

> I'll take
> a look and see if there's an easy way to allow this syntax, which -- you
> have to admit -- is fairly obscure.

I can live with broken associative arrays a bit longer if it means
time to come up with a better solution.



reply via email to

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