Re: Bug with bash emulation regarding ':'

[Peter Stephenson <Peter.Stephenson@csr.com>]

On Sun, 19 Feb 2012 15:45:15 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Hence it appears "we rely on the nested substitution to do the splitting
> we see in the top-level parameter expansion" is incorrect, at least in
> this instance?

That's good.  Maybe we're only relying on it to get the assigned value,
after all, so the splitting is done in the same order as bash (just
hitherto with different options applied at each stage).

> In fact it may be that PREFORK_SINGLE is the only thing needed there,
> and PREFORK_NOSHWORDSPLIT is extraneous?

The basic behaviour is certainly given with PREFORK_SINGLE only (spbreak
initialisation around line 1540); there's one oddity where we'll use
SHWORDSPLIT on its own to determine the default for (@) behaviour if not
forced on around line 1652.  That's rather confusing and my previous
change may already have had some impact on this, since we've reduced the
number of cases where SHWORDSPLIT is forced on.

> Although all tests still pass (except the new one introduced by 30203
> which must be tweaked), I should note the above changes the "native"
> zsh behavior as well.  I woudn't imagine this is going to cause much
> trouble -- I found no uses of ${...=...} in the default $fpath, which
> includes the whole completion suite, etc. -- but it does mean we might
> want to make it conditional upon something.  For example:

> +			    spbreak ? PREFORK_SINGLE : PREFORK_NOSHWORDSPLIT,

I suppose that's as good as anything.  Goodness knows how to document
this.  I'm not sure I really understand how the ramifications of one
option cause so much divergence internally, but as far as I can see (and
I can't, really) that should cover the two obvious cases where
SHWORDSPLIT is or is not on at the top level.  Whether it covers
explicit splitting in nested substitutions or (@) processing is another
matter.

However, given we don't tend to rely on ${...=...}, and the shenanigans
with parameter flags don't apply to POSIX, it doesn't seem worth doing
any more research, so I think this is probably as good as we need.
Thanks.

It might be worth folding this in and making 4.3.17 immediately, there's
no real point in releasing only a partial fix.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog