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

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Tue, 13 Jan 2009 19:24:09 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Tue, 13 Jan 2009 02:32:34 -0500
> Greg Klanderman <gak@klanderman.net> wrote:
> > lwm% x=::: && for v in "${(s-:-)x}" ; do echo "v= =>$v<=" ; done
> > v= =><=
> > v= =><=
> 
> Hmm...
> 
> % setopt rcexpandparam                                     
> % x=::: && for v in "${(s-:-)x}" ; do echo "v= =>$v<=" ; done
> v= =><=
> v= =><=
> v= =><=
> v= =><=
> 
> What's this got to do with RC_EXPAND_PARAM and why is the behaviour
> without that option not a bug?  Er...  I'm very glad you asked.
> 
> -- 
> Peter Stephenson <p.w.stephenson@ntlworld.com>
> Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Oh, yes.  I had to look at the code before the answer came to me,
again---I've run up against this one several times before.

It's not a bug because it's documented to do something incredibly
pointless:

  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:

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

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

Not sure why RC_EXPAND_PARAM makes it work more sensibly, however.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/