Re: surprise with echo

[Kurtis Rader <krader@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxx>
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