Re: uninvited members of associative array

[Ray Andrews <rayandrews@eastlink.ca>]

On 2022-12-16 08:30, Daniel Shahaf wrote:
> I think the better takeaway here is that the "default" (barest) syntax
> isn't always the right one.  There's any number of examples of this:
>
> - Variable expansions, «${foo}».  Scalars need to be quoted; arrays need
>    to be quoted and @'d; assocs need to be quoted, @'d, and (kv)'d.  The
>    actual meaning of unquoted «${foo}» — expand to all non-null values —
>    isn't commonly needed.
>
> - «ls *.txt» without a «--» guard.
>
> - «print -- $foo» without «-r».
>
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.  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.