28 Mart 2021 Pazar tarihinde Ilkka Virta <[email protected]> yazdı: > On Sun, Mar 28, 2021 at 10:16 AM Oğuz <[email protected]> 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 error. -- Oğuz
