Re: surprise with echo

["Lawrence Velázquez" <larryv@macports.org>]

On Dec 19, 2014, at 10:55 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> My two cents would be (well, er, my 1/2 cent), that it should be the default, *but* that the little surprise should not be there

I believe Kurtis was saying that RC_QUOTES should be enabled by default, not RC_EXPAND_PARAM.

Having array substitution be distributive by default would be much more of a "little surprise" at this point.

> b) because it seems harsh to kill an entire string because one element in it is null.

You still don't understand what's going on. The expansion only results in a null result *if the array itself is empty*. Null *elements* do not produce the same behavior.

    % emulate zsh && setopt RC_EXPAND_PARAM
    % foo=()
    % echo aaa${foo}bbb

    % foo=('')
    % echo aaa${foo}bbb
    aaabbb
    % foo=('' '' '')
    % echo aaa${foo}bbb
    aaabbb aaabbb aaabbb
    %

> c) Because the doctrine of least surprise should be followed.

Agreed. That's why enabling RC_EXPAND_PARAM by default should never happen.

> OTOH Bart just showed how the surprise can be avoided so ....

It's only a surprise if you enable the option without understanding what it does first. I actually think that zsh's behavior is more consistent and sensible. Why does it make sense to treat an empty array in the same way as an array consisting of a single null element? Do you treat null sets that cavalierly?

Consider this contrived-ish example:

    % include_dirs=(/opt/local/include /usr/include /usr/local/include)
    % clang -I${include_dirs} test.c

The expansion here would be "clang -I/opt/local/include -I/usr/include -I/usr/local/include  test.c". But:

    % include_dirs=()
    % clang -I${include_dirs} test.c

What would be the point of this expanding to "clang -I test.c"? It seems entirely reasonable to drop that word entirely and expand to "clang test.c", which is what actually happens.

vq