On 2024-04-14 08:51, Bart Schaefer wrote:
> On Sun, Apr 14, 2024 at 6:24 AM Ray Andrews<rayandrews@eastlink.ca>  wrote:
> The trouble with that "doctrine" is that what is surprising is
> subjective and context-dependent both in usage and in time.  When
> these decisions were made, the largest number of zsh adoptees would
> have been more surprised by having empty elements kept than removed.
> Mysteriously receiving error messages like
Absolutely.  It is subjective therefore a design decision, not anything 
like right or wrong.  I think the 'no negative options' rule is more 
objective tho.  Still, even recognizing the rule, there will be 
exceptions and maybe this is one of them.
> ls: : No such file or directory
>
> would have been the surprising thing.  Further, many commands neither
> understand nor do anything useful with empty string arguments, and zsh
> was intended first to be an interactive command shell and only second
> a programming language (just a better one than BSD csh).
That might be enough to close the case.  When I think of my data arrays 
it doesn't occur to me that 'ls' is going to receive it's arguments 
using the same rules.  Yeah, I've run into that -- piping array contents 
to 'ls' and having it barf at a blank.  So even as a theoretical 
discussion, what I'm suggesting would have to be unique to personal 
data, not arguments sent to ls ... but that might not be possible so ... 
I loose.  Or ... the speculative: 'no empty elements' flag would have to 
be applied to all utilities.  Anyway it's just philosophy.

But this morning's mixup is cured.  print might take "  \n  " and give 
me a new line but as far as "  ${(f)....}  " ... is concerned they are 
not the same thing and "  '\n'  " will not be removed but "   $'\n'   " 
will be removed.  I get it.  And in an assignment, it's spaces that 
delimit elements. Hard spaces will be inside ticks or $'' .

Thanks for everyone's patience.