[Top][All Lists]

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

Re: zsh style associative array assignment bug

From: Oğuz
Subject: Re: zsh style associative array assignment bug
Date: Sun, 28 Mar 2021 14:02:10 +0300

28 Mart 2021 Pazar tarihinde Ilkka Virta <itvirta@gmail.com> yazdı:

> On Sun, Mar 28, 2021 at 10:16 AM Oğuz <oguzismailuysal@gmail.com> wrote:
>> That an idea was borrowed from another shell doesn't mean it should be
>> implemented the same kludgy way. Besides, bash doesn't offer compatibility
>> with zsh.
> You don't think the realm of POSIX-ish shells already has enough
> incompatibilities
> and minor quirks between the different shells? :)

> The oldest version of Bash I ever used is 4.4.20, and if my memory serves
>> me right, it didn't regard omission of a value inside a compound
>> assignment
>> (like `foo=([bar]=)`) an error. If otherwise and it actually did, that was
>> a mistake.
> But this is an error:
>    a=([foo]=123 [bar])

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.

> Now, the syntax is different so it's not a fair comparison, really. But
> spinning up an
> empty word where none exists is not something the shell usually does
> anywhere
> else, so why should it do that here?

Pairing separate words for further processing is not something the shell
usually does anywhere else either. So why shouldn't it?

> I believe bash will eventually (if hasn't already done in devel) allow `$@'
>> and the like to expand to multiple words inside a compound assignment to
>> an
>> associative array. Being forced to trim an array to an even number of
>> elements before using it inside such an assignment would be really
>> annoying, in my opinion.
>  I wonder, what would the use case be? I could understand assigning the
> words
> from "$@" to the keys of an associative array might be useful, but where
> would
> you want to fill the keys and values, while at the same time silently
> allowing a
> missing value? Or silently dropping one. Shouldn't a script treat that as
> an error
> and have the user recheck what they're doing, the same as in any case where
> a tool gets too many or too few arguments?

The shell already allows missing values in assignments, `a=' is not an


reply via email to

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