Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: isabella parakiss <izaberina@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: quoted compound array assignment deprecated
Date: Tue, 18 Aug 2015 19:52:00 +0200
Lines: 47
Approved: bug-bash@gnu.org
Message-ID: <mailman.8555.1439920324.904.bug-bash@gnu.org>
References: <CAAZkfoJJdVc5A9WMmBcUqUMjN=2VBq6rtuoDYVO5iMQDoLjS9Q@mail.gmail.com> <55D34682.9000704@case.edu>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Cc: bug-bash <bug-bash@gnu.org>
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
In-Reply-To: <55D34682.9000704@case.edu>
Precedence: list
Xref: csiph.com gnu.bash.bug:11376

On 8/18/15, Chet Ramey <chet.ramey@case.edu> wrote:
> On 8/17/15 4:19 AM, isabella parakiss wrote:
>> Quoting is necessary in a few cases:
>>
>> $ var=foo; declare -A "arr$var=([x]=y)"
>> bash: warning: arrfoo=([x]=y): quoted compound array assignment
>> deprecated
>> $ var=foo; declare -A arr$var=([x]=y)
>> bash: syntax error near unexpected token `('
>> $ var=foo; declare -A "arr$var"=([x]=y)
>> bash: syntax error near unexpected token `('
>>
>> I don't think this should be the default behaiour...
>
> This is exactly the case for which the warning is intended.  If you want
> to construct variable names on the fly, use `eval' or don't mix
> declarations of constructed variable names with compound assignment.
>
> You can read the extensive discussion starting at
> http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html.
>
> http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00115.html is the
> newest proposal.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> 		 ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/
>

Sorry for being both pedantic and late for that discussion but what's the
point of this warning?  From my understanding, the code is still valid, so
it doesn't stop a possible attacker and it only annoys regular users.

Using eval requires an extra level of escaping on everything else, I'd
rather use declare 2>/dev/null to suppress the warning than eval...

Idea: display the warnings in -n mode, like ksh.
This way bash wouldn't produce unexpected results on existing scripts, it
wouldn't even require a new compatibility level and shopt.
What do you think about it?


---
xoxo iza