Bash declare built-in regression loses array quotations

Matt D.
Fri Jan 13 20:56:00 GMT 2017

My scripts have been updated to account for breaking changes in Bash 4.4 
and I have updated all of my Cygwin packages back to the latest version.

I am no longer receiving any assertions. Was I wrong to assume that I 
could selectively roll back Bash to 4.3 as I did?

Matt D.

On 1/13/2017 3:11 PM, Eric Blake wrote:
> On 01/13/2017 02:00 PM, Matt D. wrote:
>> I updated yesterday to the latest Cygwin x86 release which included an
>> updated Bash 4.4.5(1). This release changes the default behavior of the
>> built-in 'declare' command which is causing scripts which relied on this
>> functionality to break.
>> The following test will illustrate the change:
>> declare -A list
>> list[a]=1
>> list[b]=2
>> list[c]=3
>> declare -p | grep list=
>> On Bash 4.4.5(1) the output is:
>> declare -A list=([a]="1" [b]="2" [c]="3" )
>> Previously the result was:
>> declare -A list='([a]="1" [b]="2" [c]="3" )'
> This is an intentional upstream behavior change.  Quoting the upstream
> release notes:
>>> There are a few incompatible changes between bash-4.3 and bash-4.4.  Bash
>>> now retains the exit status only of asynchronous jobs, as opposed to all
>>> jobs.  This means that it is not possible to use `wait' to retrieve the
>>> status of a previously-completed synchronous command.  Bash no longer
>>> attempts to perform compound assignment if a variable expansion on the
>>> right-hand side of an assignment statement to `declare' or `local' has the
>>> form of a compound assignment.  There are other changes to compound array
>>> assignments used as arguments to the `declare' and `local' builtins, but
>>> those should be backwards compatible, albeit with warning messages about
>>> deprecated constructs.  Read the descriptions of the various compatibility
>>> options in COMPAT or the man page for more details.
> ...
>>> q.  The declare builtin no longer displays array variables using the compound
>>>      assignment syntax with quotes; that will generate warnings when re-used as
>>>      input, and isn't necessary.
> Both output forms should produce the same results when re-evaluated;
> except that the form with the extra '' now issues warnings (which is why
> declare -p no longer uses the extra '').
>> I can confirm that this has always been the expected output when running
>> this command on Cygwin and Linux. I run CentOS which does not track the
>> latest Bash release and I don't know the procedure to check whether this
>> is an upstream regression or not.
> It's not a regression, but an intentional change; you'll have to update
> your script to quit relying on unspecified output.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list