Re: treatment of empty strings - why is this not a bug?

[Greg Klanderman <gak@klanderman.net>]

>>>>> Bart Schaefer <schaefer@brasslantern.com> writes:

> I was hoping to just let this thread go by, but maybe I'm the only one
> still on list who's been around long enough to have an inkling of what
> is going on here.

Hi Bart, thank you for responding to this question.  I hope you and/or
Peter will entertain one more round of this thread and answer my final
two questions, then I'll happily drop it if you wish.

> Paul Falstad (original author of zsh) made a conscious decision that
> a non-empty string, even one containing some or only characters that
> appear in $IFS, was a significant item of data and should remain in
> the expansion of $@.  However, he was unwilling to deviate from the
> standard semantics of $@ to the point of treating empty strings as
> significant.

I almost think it's worse this way - you read the docs and think "Oh
great, I don't have to worry about putting all those crazy double
quotes around everything anymore to preserve my array elements",
however, you in fact do still need all those double quotes.

> Too many programs that deal with file names, for example,
> would begin spewing errors if they received empty strings in their
> argument lists when called as e.g. ls -l $@.

I don't understand how empty strings get into arrays unless one
explicitly puts them there.. and if one explicitly puts them there,
then presumably they don't want them randomly dropped.

The best reason I can come up with for this semantics is having code
like this continue to work:

    foo_arg=""
    if [[ ... ]] ; then
      foo_arg="-bar"
    fi
    foo $foo_arg

However, now that our shell has arrays, that should really be written
as:

    foo_arg=()
    if [[ ... ]] ; then
      foo_arg=("-bar")
    fi
    foo $foo_arg

and so I see no remaining need for dropping empty strings.

> The point is to be minimally surprising to the person who just doesn't
> want to think very hard about array and $IFS semantics, not to be
> entirely logically consistent to someone who analyzes the behavior in
> detail.  If you're enough of a geek to care, you're also enough of a
> geek to figure out a workaround.

Sure, I can keep using double quotes, but I don't want to given how
close zsh is to DTRT and not needing them.

You and Peter seem to be in charge here - do you both still agree that
dropping empty strings is a desirable default?

Would you guys be OK with adding an option to inhibit this?

thank you,
Greg