On Sun, Mar 28, 2021 at 10:16 AM Oğuz <oguzismailuy...@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]) 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? 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?