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: Greg Wooledge
Subject: Re: zsh style associative array assignment bug
Date: Sun, 28 Mar 2021 18:56:02 -0400

On Sun, Mar 28, 2021 at 10:01:14PM +0300, Oğuz wrote:
> On Sun, Mar 28, 2021 at 9:02 PM Eric Cook <llua@gmx.com> wrote:
> 
> > in typeset -A ary=([key]=) an explicit empty string is the value
> 
> No. An "explicit" empty string would be '', "", or something like that.
> After `=' a value is expected but it's not there, so `[key]' is assigned
> the empty string.

Consider this assignment command:

x=

It's syntactically valid, and it assigns the empty string to the variable x.

It's perfectly reasonable, therefore, for

a=([key]=)

to assign the empty string to a[key].  You don't need '' or "" or whatever.

Now, as far as hash=(a b c) goes, I don't have a strong opinion about it.
Some of the other languages that have such a feature treat it as an error.
We've already heard from zsh.  Here's Tcl:

% array set hash {a b c}
list must have an even number of elements

Perl does what bash does, kinda:

unicorn:~$ perl -e 'use Data::Dumper; %hash=qw(a b c); print Dumper(\%hash);'
$VAR1 = {
          'a' => 'b',
          'c' => undef
        };

Python is different:

>>> y = ["a", "b", "c", "d"]
>>> dict(zip(y[::2], y[1::2]))
{'a': 'b', 'c': 'd'}
>>> x = ["a", "b", "c"]
>>> dict(zip(x[::2], x[1::2]))
{'a': 'b'}

It seems to discard the last (unmatched) value.  Also, dear gods, what
is that horrible syntax they forced me to google for... and it took MANY
tries to find it, too.

So, that's 2 votes for error, 2 votes for using the empty string (or
null/undef) as the last value, and 1 vote for silently dropping the
last key.  Definitely not a consensus.



reply via email to

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