Re: uninvited members of associative array

["Daniel Shahaf" <d.s@daniel.shahaf.name>]

Dominik Vogt wrote on Fri, 16 Dec 2022 19:04 +00:00:
> On Fri, Dec 16, 2022 at 10:21:28AM -0800, Ray Andrews wrote:
>> Yeah.  I'm sure many of my own travails have been due to that kind of ...
>> well, one could say 'shortcutting', but more often it's simply not
>> understanding the vulnerability of unquoted vars. As a few weeks ago, when
>> what was it ... something unquoted with '[]' in it tried to expand to a list
>> of files.  It's far to late to do anything about it design wise, but if it
>> were up to me the shells would have evolved from their warm little ponds
>> with a 'positive option' mentality vs. the 'negative option' that we
>> currently have.  Basically: If I want something I'll ask for it. If I want a
>> var to expand to filenames I'll request that.

You mean that you wrote foo[bar] and didn't realize that was
a globbing syntax too?  zsh can't disable features because you don't
know them.  I suppose you could go ahead and disable all glob characters
other than those you know, or perhaps you could propose a GLOB_VERIFY
option akin to HIST_VERIFY.

>> If I want empty elements
>> removed from an array I'll say so.   As it is zsh loves to do helpful things
>> whether you want them or not  and you have to ask for the exemption.  Mostly
>> by quoting but the world would have been simpler if it had been the other
>> way. Dunno, maybe not.  When one is dealing on the command line, probably
>> file-centrism makes sense.  But when it's variable contents the opposite is
>> true.  Anyway the thing is to learn the lesson early: quote.
>
> I think you have a grave misconception of shells.  Shells are
> basically command line interpreters with some text processing.  A
> command line is a string with shell specific instructions to
> generate a final list of constant strings.  These are then
> interpreted as a command name and its arguments.  There's no
> conception of symbolic values; all input is just text.  Shells are
> are not "programming languages".  The shell does not know about
> file names on the command line, it just expands strings to
> filenames if they contain globbing patterns.

Yeah, the syntax rules are well-defined, but they aren't always
intuitive.  I don't know of any other language that does null elision on
arrays, for instance: in most languages, if you loop over an array that
contains ('foo' '' 'bar'), you get three iterations.  In zsh you get two
unless you specifically request three.

In other words, the "default" syntax (the one with the fewest tokens)
doesn't give the should-be-default behaviour.