"${(s.:.)foo} and rc_expand_param

"${(s.:.)foo} and rc_expand_param

[Frank Terbeck]

Hey list,

Here is another thing I can't quite understand.

First, two excerpts from the manual:

  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’.
[...]

  s:string:
      Force field splitting at the separator string.  Note that a string
      of two or more characters means that all of them must match in
      sequence; this differs from the treatment of two or more
      characters in the IFS parameter.  See also the = flag and the
      SH_WORD_SPLIT option.

      For historical reasons, the usual behaviour that empty array
      elements are retained inside double quotes is disabled for arrays
      generated by splitting; hence the following:

             line="one::three"
             print -l "${(s.:.)line}"

      produces two lines of output for one and three and elides the
      empty field.  To override this behaviour, supply the "(@)" flag as
      well, i.e.  "${(@s.:.)line}".

Now, let's see what's happening:

zsh% foo="bar::baz"
zsh% print -l "${(s.:.)foo}"
bar
baz

Okay, this I expected, but now:

zsh% setopt rc_expand_param
zsh% print -l "${(s.:.)foo}"
bar

baz

This I did not; from the manual I'd expect to only see (@s.:.) pick up
the empty field in $foo.

Am I missing something here or is this a bug?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: "${(s.:.)foo} and rc_expand_param

[Bart Schaefer]

On Mar 6,  8:13pm, Frank Terbeck wrote:
} Subject: "${(s.:.)foo} and rc_expand_param
}
}   s:string:
}       For historical reasons, the usual behaviour that empty array
}       elements are retained inside double quotes is disabled for arrays
}       generated by splitting; hence the following:
} 
} zsh% setopt rc_expand_param
} zsh% print -l "${(s.:.)foo}"
} bar
} 
} baz
} 
} Am I missing something here or is this a bug?

I believe zsh is being faithful to the "rc" shell's behavior here.  The
doc note about "historical reasons" was added pretty recently, as was
the override of that behavor that's possible by using @s, so it's most
likely that there was always and intentionally this exception but that
it was missed when the doc was updated.

--