surprise with echo

surprise with echo

[Ray Andrews]

    test()
    {

       echo  "echoing1: $@"
       echo  "echoing2: $*"
       echo  "echoing3: $* $@ killed"
       echo  "echoing4: $@ $* dead"
    }

    $  test

    echoing2:

... that catches me completely by surprise. " $@ "
anywhere in the string kills it dead.  I traced it back
to:

setopt rc_expand_param

Why should it do that? It's very cool what it permits
as explained in 'the book' p. 288, but is the above
part and parcel of that?

Of course there's nothing to print, but why kill the
entire string?  Something about a null array?
Can that be prevented?  It's all fine if there is an
argument, of course.  Is this a feature?  One could
deliberately design it  so that nothing gets printed
in case of no argument, still it seem counterintuitive.

Re: surprise with echo

[Bart Schaefer]

On Dec 18,  5:24pm, Ray Andrews wrote:
}
} Why should it do that? It's very cool what it permits
} as explained in 'the book' p. 288, but is the above
} part and parcel of that?

The doc spells this out explicitly:

RC_EXPAND_PARAM (-P)
     Array expansions of the form `FOO${XX}BAR', where the parameter XX
     is set to (A B C), are substituted with `FOOABAR FOOBBAR FOOCBAR'
     instead of the default `FOOA B CBAR'.  Note that an empty array
     will therefore cause all arguments to be removed.

} Can that be prevented?

Only by turning off the option, or by doing e.g. ${@:-''} so that the
expansion is the empty string rather than the empty array.

} Is this a feature?

It's how array expansion works in the "rc" shell, which is the source
from which this behavior is borrowed.  There's probably an "rc" list
somewhere where you might get an explanation.

Re: surprise with echo

[Lawrence Velázquez]

On Dec 18, 2014, at 10:06 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:

> On Dec 18,  5:24pm, Ray Andrews wrote:
> 
> } Can that be prevented?
> 
> Only by turning off the option, or by doing e.g. ${@:-''} so that the
> expansion is the empty string rather than the empty array.

Also note that "preventing" it would amount to treating an empty array
the same as an array containing a single null value, which is currently
not the case:

    % emulate zsh && setopt RC_EXPAND_PARAM
    % foo=()
    % echo "abc${foo[*]}def"
    abcdef
    % echo "abc${foo[@]}def"

    % foo=('')
    % echo "abc${foo[*]}def"
    abcdef
    % echo "abc${foo[@]}def"
    abcdef

You're making quite a few assumptions about how positional parameters
and array substitution work. For instance, the fact that you're using
double quotes (which affects the expansion of $foo[*] versus $foo[@]) is
clouding your understanding of how RC_EXPAND_PARAM works. Observe:

    % emulate zsh && setopt RC_EXPAND_PARAM
    % foo=()
    % echo "abc${foo[*]}def"
    abcdef
    % echo abc${foo[*]}def

    %

Please read zshparam(1).

vq

Re: surprise with echo

[Ray Andrews]

On 12/18/2014 07:20 PM, Lawrence Velázquez wrote:
> You're making quite a few assumptions about how positional parameters 
> and array substitution work. 
I only just started experimenting with it.  In the case I mentioned, it 
just
took me by surprise that it killed the whole string. It was in a 
function that
had just ignored any null strings, then I set the option and the function
was busted.  Now I know why, so it's all fine. To be honest it never even
occurred to me that command line args would be affected.  Anyway I get
it now, thanks.

Re: surprise with echo

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

FWIW, the type of learning and experimentation you are undergoing is
extremely useful to yourself and the project. The problem is the difference
between proprietary and open source software. With proprietary software you
have a phone number (email address, web site, etc) that you can use to tell
the company you found a problem and expect it to be fixed. Since you were
paying for support you have, in theory, some leverage.

With open source software reporting a problem is less likely to result in a
fix. However, if you also propose a fix or can convince a contributor to
the project to champion your cause the odds of the problem being fixed are
greatly increased. So it helps if you provide the simplest possible
examples for reproducing the problem and a clear description.

On Thu, Dec 18, 2014 at 10:09 PM, Ray Andrews <rayandrews@eastlink.ca>
wrote:
>
> On 12/18/2014 07:20 PM, Lawrence Velázquez wrote:
>
>> You're making quite a few assumptions about how positional parameters and
>> array substitution work.
>>
> I only just started experimenting with it.  In the case I mentioned, it
> just
> took me by surprise that it killed the whole string. It was in a function
> that
> had just ignored any null strings, then I set the option and the function
> was busted.  Now I know why, so it's all fine. To be honest it never even
> occurred to me that command line args would be affected.  Anyway I get
> it now, thanks.
>
>

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: surprise with echo

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On 12/18/2014 10:30 PM, Kurtis Rader wrote:
> FWIW, the type of learning and experimentation you are undergoing is 
> extremely useful to yourself and the project.

Thanks Kurtis, I appreciate that. Several people have said the same thing
privately, OTOH I do worry about driving folks crazy, and some have
expressed irritation.

>  So it helps if you provide the simplest possible examples for 
> reproducing the problem and a clear description.
>
Of course, but at my stage of development, the issue is usually determining
if I even understand things correctly.

Re: surprise with echo

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]

Bart, I don't see how the zsh behavior is compatible with the Plan 9 rc
shell. More on that below.

Ray, You really do not want to set non-default zsh options related to
emulating the behavior of a different shell. If, for example, you want zsh
to behave like ksh93, or csh, or the Plan 9 rc shell you're probably better
off just using those shells. If you explicitly change the behavior of zsh
by setting options you can't reasonably complain unless the resulting
behavior contradicts the documentation.

Bart, It appears to me that zsh treatment of "setopt rc_expand_param" is
*not* consistent with the Plan 9 rc shell.

As a grey-beard (I fell in love with UNIX in the 1980's when the C-shell
was bleeding edge) I'm familiar with all the major variants of shells and
kernels. Thus I was vaguely familiar with Plan 9. Having said that I have
only spent a few hours playing with Plan 9 in the distant past when it was
bleeding edge. Since this issue intrigued me I did a

sudo apt-get install rc


on my Ubuntu VM instance. As best I can tell the behavior exhibited by Plan
9 rc shell only applies to explicit string concatenation. And even then it
does not cause the resulting string to be completely omitted.

It is possible, even likely, I'm missing the point of the RC_EXPAND_PARAM
emulation option since I've never used the Plan 9 rc shell before today. If
that is true then I would argue the zsh documentation needs to be expanded
with examples showing the mapping of rc to zsh constructs that are affected
by this option. I created a shell script containing

#!/usr/bin/rc

echo echoing1: $@
echo echoing2: $*
echo echoing3: $* $@ killed
echo echoing4: $@ $* dead

echo aaa^$*^bbb
echo ccc^$@^ddd


Then ran it:

$ /tmp/x
echoing1:
echoing2:
echoing3: killed
echoing4: dead
aaabbb
cccddd

$ /tmp/x A B C
echoing1:
echoing2: A B C
echoing3: A B C killed
echoing4: A B C dead
aaaAbbb aaaBbbb aaaCbbb
cccddd


Notice that in the first case the "aaa...bbb" string was not elided. And
neither invocation affected the echo statements provided by Ray. I
appreciate that zsh is not rc and they have different syntax and semantics
(e.g., "$@" does not appear to mean anything in the rc shell). Nonetheless,
at a first glance it does appear that the zsh RC_EXPAND_PARAM option
behavior is not consistent with the rc shell.


On Thu, Dec 18, 2014 at 7:06 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:
>
> On Dec 18,  5:24pm, Ray Andrews wrote:
> }
> } Why should it do that? It's very cool what it permits
> } as explained in 'the book' p. 288, but is the above
> } part and parcel of that?
>
> The doc spells this out explicitly:
>
> RC_EXPAND_PARAM (-P)
>      Array expansions of the form `FOO${XX}BAR', where the parameter XX
>      is set to (A B C), are substituted with `FOOABAR FOOBBAR FOOCBAR'
>      instead of the default `FOOA B CBAR'.  Note that an empty array
>      will therefore cause all arguments to be removed.
>
> } Can that be prevented?
>
> Only by turning off the option, or by doing e.g. ${@:-''} so that the
> expansion is the empty string rather than the empty array.
>
> } Is this a feature?
>
> It's how array expansion works in the "rc" shell, which is the source
> from which this behavior is borrowed.  There's probably an "rc" list
> somewhere where you might get an explanation.
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: surprise with echo

[Lawrence Velázquez]

On Dec 18, 2014, at 11:14 PM, Kurtis Rader <krader@skepticism.us> wrote:

> I created a shell script containing
> 
> #!/usr/bin/rc
> 
> echo echoing1: $@
> echo echoing2: $*
> echo echoing3: $* $@ killed
> echo echoing4: $@ $* dead
> 
> echo aaa^$*^bbb
> echo ccc^$@^ddd

This doesn't reproduce the environment Ray had because your positional parameters get substituted into their own words.

% cat /private/tmp/x.zsh
echo echoing1: $@
echo echoing2: $*
echo echoing3: $* $@ killed
echo echoing4: $@ $* dead
echo aaa^$*^bbb
echo ccc^$@^ddd
echo
echo "echoing5: $@"
echo "echoing6: $*"
echo "echoing7: $* $@ killed"
echo "echoing8: $@ $* dead"
% zsh !$
zsh /private/tmp/x.zsh
echoing1:
echoing2:
echoing3: killed
echoing4: dead
aaa^^bbb
ccc^^ddd

echoing5: 
echoing6: 
echoing7:   killed
echoing8:   dead
% zsh -P !$
zsh -P /private/tmp/x.zsh
echoing1:
echoing2:
echoing3: killed
echoing4: dead




echoing6: 


%

vq

Re: surprise with echo

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

You apparently missed my point that script was meant to be run by a Plan 9
rc shell. See the "#!/usr/bin/rc" at the top. It was meant to exhibit the
behavior of the shell the zsh RC_EXPAND_PARAM option is meant to emulate.

On Thu, Dec 18, 2014 at 8:39 PM, Lawrence Velázquez <larryv@macports.org>
wrote:
>
> On Dec 18, 2014, at 11:14 PM, Kurtis Rader <krader@skepticism.us> wrote:
>
> > I created a shell script containing
> >
> > #!/usr/bin/rc
> >
> > echo echoing1: $@
> > echo echoing2: $*
> > echo echoing3: $* $@ killed
> > echo echoing4: $@ $* dead
> >
> > echo aaa^$*^bbb
> > echo ccc^$@^ddd
>
> This doesn't reproduce the environment Ray had because your positional
> parameters get substituted into their own words.
>
> % cat /private/tmp/x.zsh
> echo echoing1: $@
> echo echoing2: $*
> echo echoing3: $* $@ killed
> echo echoing4: $@ $* dead
> echo aaa^$*^bbb
> echo ccc^$@^ddd
> echo
> echo "echoing5: $@"
> echo "echoing6: $*"
> echo "echoing7: $* $@ killed"
> echo "echoing8: $@ $* dead"
> % zsh !$
> zsh /private/tmp/x.zsh
> echoing1:
> echoing2:
> echoing3: killed
> echoing4: dead
> aaa^^bbb
> ccc^^ddd
>
> echoing5:
> echoing6:
> echoing7:   killed
> echoing8:   dead
> % zsh -P !$
> zsh -P /private/tmp/x.zsh
> echoing1:
> echoing2:
> echoing3: killed
> echoing4: dead
>
>
>
>
> echoing6:
>
>
> %
>
> vq



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: surprise with echo

[Lawrence Velázquez]

On Dec 19, 2014, at 12:19 AM, Kurtis Rader <krader@skepticism.us> wrote:

> You apparently missed my point that script was meant to be run by a Plan 9 rc shell. See the "#!/usr/bin/rc" at the top. It was meant to exhibit the behavior of the shell the zsh RC_EXPAND_PARAM option is meant to emulate.

I did not miss your point, but I did misunderstand some of the rc-specific syntax you used, and I think your test examples conflated many of the issues being discussed.

However, simpler test cases do support your position.

% cat >/private/tmp/x <<'EOF'
heredoc> foo=()
heredoc> echo 1: aaa^$foo^bbb
heredoc> 
heredoc> foo=('')
heredoc> echo 2: aaa^$foo^bbb
heredoc> 
heredoc> foo=(1 2)
heredoc> echo 3: aaa^$foo^bbb
heredoc> EOF
% rc /private/tmp/x
1: aaabbb
2: aaabbb
3: aaa1bbb aaa2bbb
%

vq

Re: surprise with echo

[Bart Schaefer]

On Dec 18,  8:14pm, Kurtis Rader wrote:
}
} Bart, It appears to me that zsh treatment of "setopt rc_expand_param" is
} *not* consistent with the Plan 9 rc shell.

That would not be surprising.  A number of rc and ksh features were put
into zsh based entirely on Paul Falstad's interpretation of the other
shells' documentation, with no access to an actual implementation of
the other shell to compare results.  I personally have never tried out
the Plan 9 shell.

} As a grey-beard (I fell in love with UNIX in the 1980's when the
} C-shell was bleeding edge) I'm familiar with all the major variants of
} shells and kernels.

We ought to have a secret handshake or something by this point.  I led
the team that ported Z-Mail to 29 different UNIX variants and three
windowing systems, back in the 90's, after spending my grad school
years in the 80s parallelizing applications for the Sequent machine
and playing with Smalltalk on a Tektronix 4315 running UTek.  Did you
ever get to program Occam in the folding editor, for Transputer apps?
(Good lord it's been a long time since I uttered any of those words.)

-- 
Barton E. Schaefer

Re: surprise with echo

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Thu, Dec 18, 2014 at 9:57 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:
>
>
> } As a grey-beard (I fell in love with UNIX in the 1980's when the
> } C-shell was bleeding edge) I'm familiar with all the major variants of
> } shells and kernels.
>
> We ought to have a secret handshake or something by this point.  I led
> the team that ported Z-Mail to 29 different UNIX variants and three
> windowing systems, back in the 90's, after spending my grad school
> years in the 80s parallelizing applications for the Sequent machine
> and playing with Smalltalk on a Tektronix 4315 running UTek.  Did you
> ever get to program Occam in the folding editor, for Transputer apps?
> (Good lord it's been a long time since I uttered any of those words.)


I think we already have a semi-secret handshake. I joined Sequent Computer
Systems around 1991 as a support technician. Because I was the only
software engineer on that team I wrote a lot of their support tools. Which
included supporting (but mostly arguing against) using Smalltalk as the
basis for a expert system to support our customers. Those were the days, as
you allude to, when things like a X Window system terminal (i.e., client)
was bleeding edge. I've never written a line of code in Occam but remember
reading about it and debating its merits.


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: surprise with echo

[Ray Andrews]

On 12/18/2014 10:08 PM, Kurtis Rader wrote:
> I think we already have a semi-secret handshake. I joined Sequent 
> Computer Systems around 1991 as a support technician. Because I was 
> the only software engineer on that team I wrote a lot of their support 
> tools. Which included supporting (but mostly arguing against) using 
> Smalltalk as the basis for a expert system to support our customers. 
> Those were the days, as you allude to, when things like a X Window 
> system terminal (i.e., client) was bleeding edge. I've never written a 
> line of code in Occam but remember reading about it and debating its 
> merits. 
I love this historical banter.  How many guys still with the project 
overlapped
with Falstad? Bart of course, anyone else? So vital to have known the 
mind of the
master.

Re: surprise with echo

[Bart Schaefer]

On Dec 18, 10:58pm, Ray Andrews wrote:
}
} I love this historical banter. How many guys still with the project
} overlapped with Falstad? Bart of course, anyone else?

I may be the only one.  Paul was my employee for a while immediately
after he graduated college.

} So vital to have known the mind of the master.

Chuckle.  When zsh was written he was a brilliant but inexperienced
programmer, trying to help his csh-afflicted classmates get used to
Bourne shell scripting.  He didn't continue working on zsh for long
after entering the real world.

Much the same could be said of the man who added the programmable
completion system several years later.

Re: surprise with echo

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Fri, Dec 19, 2014 at 6:55 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:
>
> On Dec 18, 10:58pm, Ray Andrews wrote:
>
> } So vital to have known the mind of the master.
>
> Chuckle.  When zsh was written he was a brilliant but inexperienced
> programmer, trying to help his csh-afflicted classmates get used to
> Bourne shell scripting.  He didn't continue working on zsh for long
> after entering the real world.
>

We're definitely getting a bit off-topic but I have to second your
"csh-afflicted" comment. My team (before Sequent hired me) briefly adopted
use of csh (on a Sequent Symmetry with four 20 MHz i386 CPUs and 32 MB not
GB of memory :-) for both interactive use and scripting. Given the other
options (essentially just the Bourne shell) it was a huge improvement for
interactive use. But for scripting it was a nightmare. Google "csh
considered harmful" for details. Thankfully the Korn shell (ksh) soon
became available.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: surprise with echo

[Ray Andrews]

On 12/19/2014 06:55 PM, Bart Schaefer wrote:
> On Dec 18, 10:58pm, Ray Andrews wrote:
> }
> } I love this historical banter. How many guys still with the project
> } overlapped with Falstad? Bart of course, anyone else?
>
> I may be the only one.  Paul was my employee for a while immediately
> after he graduated college.
>
> } So vital to have known the mind of the master.
>
> Chuckle.  When zsh was written he was a brilliant but inexperienced
> programmer, trying to help his csh-afflicted classmates get used to
> Bourne shell scripting.  He didn't continue working on zsh for long
> after entering the real world.
Well well ... so who, really, is/was the master, I asks myself? ...
Why did he decide on a new shell vs. working on/with bash?
Does he keep in touch?
>
> Much the same could be said of the man who added the programmable
> completion system several years later.
>

Re: surprise with echo

[Bart Schaefer]

On Dec 19,  7:49pm, Ray Andrews wrote:
}
} Why did [Paul] decide on a new shell vs. working on/with bash?

I never really asked.

It may have been that he had to write a simple shell anyway for a
class project.  I wrote one once.  It's a good way to demonstrate
that you understand the concepts of unix process control, signaling,
and file descriptor I/O.

However, bash was always going to be the bourne shell at heart, and
zsh was meant to combine the best features of csh and sh in a way
that would be easily understood by someone who learned csh first.

Bash would never have adopted the default array behavior of zsh,
among other things.

} Does he keep in touch?

We're friends on Facebook.  His hobbies now include writing iPhone apps,
and geocaching.  He hasn't looked at any of the zsh lists in years as
far as I know.

Re: surprise with echo

[Ray Andrews]

On 12/19/2014 08:40 PM, Bart Schaefer wrote:
> We're friends on Facebook.  His hobbies now include writing iPhone apps,
> and geocaching.  He hasn't looked at any of the zsh lists in years as
> far as I know.
A dead-beat dad ;-)

Re: surprise with echo

[Ray Andrews]

On 12/18/2014 08:14 PM, Kurtis Rader wrote:

Kurtis,
>
> Ray, You really do not want to set non-default zsh options related to 
> emulating the behavior of a different shell.
It's ok, I'm just fooling around with stuff I read in Peter and Oliver's 
book.  They recommend 'rc_expand_param', so I'm trying it out.  I expect 
bumps.

...
Nonetheless, at a first glance it does appear that the zsh 
RC_EXPAND_PARAM option behavior is not consistent with the rc shell.

Well then! What Kurtis shows happening sure looks friendlier to me. So ...

Re: surprise with echo

[Oliver Kiddle]

Kurtis Rader wrote:

> It is possible, even likely, I'm missing the point of the RC_EXPAND_PARAM
> emulation option since I've never used the Plan 9 rc shell before today. If

I've never regarded the rc_expand_param and rc_quotes options as being
there to emulate rc. They are merely inspired by rc.

Both are useful features and are worth enabling in an interactive
configuration but don't expect your rc scripts to even come close to
working in zsh. Note in particular that in rc, ^ is a special operator
for joining strings. rc_expand_param doesn't enable support for that.

Incidentally, I have actually used rc for a while because it was the
default shell on the CS department systems at the university I went to.
In terms of syntax and design, it is much better than sh but also about
as functional as sh from an interactive perspective.

> On Thu, Dec 18, 2014 at 7:06 PM, Bart Schaefer <schaefer@brasslantern.com>
> wrote:
> >
> > Only by turning off the option, or by doing e.g. ${@:-''} so that the
> > expansion is the empty string rather than the empty array.

$^^@ will also do the job of disabling the option.

Oliver

Re: surprise with echo

[Bart Schaefer]

On Dec 19, 12:21pm, Oliver Kiddle wrote:
}
} I've never regarded the rc_expand_param and rc_quotes options as being
} there to emulate rc. They are merely inspired by rc.

This is also a truism.

} > > Only by turning off the option, or by doing e.g. ${@:-''} so that the
} > > expansion is the empty string rather than the empty array.
} 
} $^^@ will also do the job of disabling the option.

Right.  The important detail is that XX${@:-''}ZZ will produce similar
results whether or not $@ is empty, whereas XX${^^@}ZZ does something
different when $@ is NOT empty.  (Assuming in both cases rcexpandparam
is set.)

Re: surprise with echo

[Kurtis Rader]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

On Fri, Dec 19, 2014 at 3:21 AM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>
> Kurtis Rader wrote:
>
> > It is possible, even likely, I'm missing the point of the RC_EXPAND_PARAM
> > emulation option since I've never used the Plan 9 rc shell before today.
> If
>
> I've never regarded the rc_expand_param and rc_quotes options as being
> there to emulate rc. They are merely inspired by rc.


Fair enough. And I don't have any objection to the options per se. In fact
I think the behavior provided by the rc_quotes option should have been the
default from day one (hindsight is wonderful). What I do object to is the
implication that the semantics of the rc_expand_param option will match
that of the rc shell. Yes, the zsh documentation is quite clear that isn't
true but the name of the option can easily lead someone to think otherwise.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: surprise with echo

[Ray Andrews]

On 12/19/2014 06:58 PM, Kurtis Rader wrote:
> Fair enough. And I don't have any objection to the options per se. In 
> fact I think the behavior provided by the rc_quotes option should have 
> been the default from day one (hindsight is wonderful). What I do 
> object to is the implication that the semantics of the rc_expand_param 
> option will match that of the rc shell. Yes, the zsh documentation is 
> quite clear that isn't true but the name of the option can easily lead 
> someone to think otherwise. 
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, a) because 
that would be more true to the name of the option, and b) because it 
seems harsh to kill an entire string because one element in it is null.  
Does that sort of thing happen anywhere else? c) Because the doctrine of 
least surprise should be followed.  OTOH Bart just showed how the 
surprise can be avoided so ....

Re: surprise with echo

[Lawrence Velázquez]

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

Re: surprise with echo

[Ray Andrews]

On 12/19/2014 09:08 PM, Lawrence Velázquez wrote:
> 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. 

Yes, I understand it, I just spoke poorly.

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

I'd say that if it worked the way Kurtis showed that it's 'supposed' to work
then that would be the best of all possible worlds.  But it's just my 1/2
cent, I don't value my own opinion on this beyond that.
>> 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.

Too true.

 >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
Well, whatever more experienced people think.  I have no skin in the 
issue, but my intuitive sense of it is than a 'nothing' should just be 
nothing, but it shouldn't go killing things that are not nothing.  It's 
probably not debatable, and it doesn't matter anyway.  Especially if 
there are other examples of that sort of thing, then it might not be 
considered a surprise.  But if that's the only place where it happens, 
then I'd say it's questionable. That expansion is sure cool, but I don't 
think it should kill entire strings: echo "what's wrong with this 
string? $@", especially since it leaves it alone if we use " $* ".  
Dunno.  All I can say is that rc itself seems to agree with me.

Re: surprise with echo

[ZyX]

20.12.2014, 08:39, "Ray Andrews" <rayandrews@eastlink.ca>:
> On 12/19/2014 09:08 PM, Lawrence Velázquez wrote:
>>  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.
>
> Yes, I understand it, I just spoke poorly.
>>  Agreed. That's why enabling RC_EXPAND_PARAM by default should never
>>  happen.
>
> I'd say that if it worked the way Kurtis showed that it's 'supposed' to work
> then that would be the best of all possible worlds.  But it's just my 1/2
> cent, I don't value my own opinion on this beyond that.
>>>  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.
>
> Too true.
>> 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
> Well, whatever more experienced people think.  I have no skin in the
> issue, but my intuitive sense of it is than a 'nothing' should just be
> nothing, but it shouldn't go killing things that are not nothing.  It's
> probably not debatable, and it doesn't matter anyway.  Especially if
> there are other examples of that sort of thing, then it might not be
> considered a surprise.  But if that's the only place where it happens,
> then I'd say it's questionable. That expansion is sure cool, but I don't
> think it should kill entire strings: echo "what's wrong with this
> string? $@", especially since it leaves it alone if we use " $* ".
> Dunno.  All I can say is that rc itself seems to agree with me.

When thinking about RC_EXPAND_PARAM I think of it as applying `map` to an array that prepends/appends strings. As such `-I${include_dirs}` with empty $include_dirs does not kill an a string. It just transforms an empty array to an empty array and that’s all. You don’t think that e.g. `map(lambda v: '-I' + v, lst)` (Python) should produce `['-I']` for the empty list, do you?

I though use $^ and not RC_EXPAND_PARAM in which case it is clear that an array is treated specially. It also does not work inside `""` which makes it even more clear. If RC_EXPAND_PARAM was on always I would find it logical, but unexpected and not convenient.

Re: surprise with echo

[Ray Andrews]

On 12/18/2014 07:06 PM, Bart Schaefer wrote:
> RC_EXPAND_PARAM (-P)
>       Array expansions of the form `FOO${XX}BAR', where the parameter XX
>       is set to (A B C), are substituted with `FOOABAR FOOBBAR FOOCBAR'
>       instead of the default `FOOA B CBAR'.  Note that an empty array
>       will therefore cause all arguments to be removed.
Nuts, at the time it didn't sink in that a function with no arguments 
matches
that situation ... and then I go on to suggest that very thing myself.
Pardon, that was thick headed. Still, it is a bit brutal. Nevermind, 
it's there
when needed.