bug-bash
[Top][All Lists]
Advanced

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

Re: zsh style associative array assignment bug


From: L A Walsh
Subject: Re: zsh style associative array assignment bug
Date: Mon, 29 Mar 2021 14:01:15 -0700
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

On 2021/03/28 11:02, Eric Cook wrote:
On 3/28/21 7:02 AM, Oğuz wrote:
As it should be. `[bar]' doesn't qualify as an assignment without an equals 
sign, the shell thinks you're mixing two forms of associative array assignment 
there.

In the new form, that a key is listed inside a compound assignment alone 
implies that it was meant to be assigned a value. In my mind, `a=(foo 123 bar)' 
translates to `a=([foo]=123 [bar]=)'. It makes sense.

That is the point that i am making, in typeset -A ary=([key]=) an explicit 
empty string is the value, but in the case of typeset -A ary=([key]) it was 
historically an error. So why should an key without a value now be acceptable?
---
   Maybe historically it was an error and now it is fixed?
   As for perl, if you turn on warnings, the 3 element assignment
is treated as a warning:

my %hash=(qw(a b c));'
Odd number of elements in hash assignment at -e line 2.

   But errors usually prevent execution, so you have no choice about
whether to allow an odd number of elements.  However, if it is
not an error, you can check the input to verify that there are an even
number of elements and handle it as you wish.
Also, note, an assignment with nothing after the '=' sign is valid
syntax in bash.  So why should it fail here?





reply via email to

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