On Fri, Jan 8, 2021 at 2:14 PM Koichi Murase <myoga.mur...@gmail.com> wrote:
> This topic actually pops up occasionally. FYI, you can also see the > following discussions: > > https://lists.gnu.org/archive/html/bug-bash/2014-06/msg00003.html > https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00154.html > https://lists.gnu.org/archive/html/bug-bash/2015-02/msg00066.html > > 2021年1月8日(金) 18:21 Oğuz <oguzismailuy...@gmail.com>: > > `(( assoc[\$key]++ ))' works as usual, but this is not documented as > > far as I know, > > This is explained in the first link above by quoting two sentences in > the document, but I agree with you that this is so non-trivial that > it's worth explicitly documenting IMHO. > You are right, the first quote explains it. > > Considering that the following two works, it doesn't make much sense > > that `(( assoc[$key]++ ))' doesn't. > > I think the POSIX expansion order should be applied to, for example, > $((assoc[$key]++)). In this case, the arithmetic evaluation of the > whole expression should be performed only after $key in > $((assoc[$key]++)) is expanded. There is no reason to introduce a > different expansion rule of `((...))' from that of `$((...))'. It > feels a bit strange to me to expand `$key' in `(( assoc[$key]++ ))' > after determining the arithmetic structure thinking the normal > expansion order. > But there already is a different expansion rule. While `(( assoc['$key']++ ))' works, `: $(( assoc['$key']++ ))' fails with a bad subscript error. > > It would be better if at least quoting the key by means of parameter > > transformation or `printf %q' worked, because these are the first > > workarounds that come to mind; > > This is maybe a good idea. From Bash 5.1, the single quotation is > not a subject to the quote removal of `(( ... ))', so we can use the > single quotation as a part of the arithmetic expression. We can just > introduce the string literal of the form '...' or $'...' in the > arithmetic evaluator. > $'...' would be nice, it would even fix existing scripts that rely on @Q or %q. > -- > Koichi >
