[Top][All Lists]

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

Re: zsh style associative array assignment bug

From: Ilkka Virta
Subject: Re: zsh style associative array assignment bug
Date: Sun, 28 Mar 2021 13:00:53 +0300

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
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])

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
else, so why should it do that here?

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
from "$@" to the keys of an associative array might be useful, but where
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?

reply via email to

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