Word splitting/joining inside [[ ]]

Word splitting/joining inside [[ ]]

[Bart Schaefer]

I have a string of words:

words="I have a string of words"

What I want to learn is whether the words are already in sorted order.

So my thought is to split the string on spaces, sort the resulting array,
and join the string back together again on spaces, and compare that string
to the original string.

So I wrote this:

[[ $words = ${(on)=words} ]]

Doesn't work.  It's always true.  Confused, I setopt xtrace and discover:

torch% [[ $words != ${(on)=words} ]]
+zsh:6> [[ 'I have a string of words' = I\ have\ a\ string\ of\ words ]]

Oh, I have the (on) at the wrong nesting level.

torch% [[ $words = ${(on)${=words}} ]]
+zsh:7> [[ 'I have a string of words' == I\ have\ a\ string\ of\ words ]]

Er, apparently that's not it.  Works fine outside [[ ]]:

torch% print ${(on)${=words}}
+zsh:8> print a have I of string words
a have I of string words

But then so does the original:

torch% print ${(on)=words} 
+zsh:9> print a have I of string words
a have I of string words

By accident I discovered that adding a supposedly-meaningless extra level
of nested expansion makes it work:

torch% [[ $words = ${${(on)=words}} ]]
+zsh:12> [[ 'I have a string of words' == a\ have\ I\ of\ string\ words ]]

What's going on here?

Re: Word splitting/joining inside [[ ]]

[Peter Stephenson]

On Fri, 11 Dec 2015 20:31:47 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> [[ $words = ${(on)=words} ]]
> 
> Doesn't work.  It's always true.  Confused, I setopt xtrace and discover:
>>>
> By accident I discovered that adding a supposedly-meaningless extra level
> of nested expansion makes it work:
> 
> torch% [[ $words = ${${(on)=words}} ]]
> +zsh:12> [[ 'I have a string of words' == a\ have\ I\ of\ string\ words ]]
> 
> What's going on here?

I guess this is something to do with the effect of singsub() and the
PREFORK_SINGLE flag which propagates into paramsubst() but not further
into multsub() which handles nested expansion.  There are likely to be
lots of combinations of effects like this that have never been thought
through.

In particular, forcing single substitution at the top level inhibits
various things happening (sometimes even if you've explicitly indicated
an affect that would later undo them) whereas the combination of multsub
and a paramsubst on top of it is smarter about trying to work out the
end effect.  So in your second case multsub produces array behaviour which
the top level paramsubst can then rationalise back down to a single
expression, while in your first case there's no leeway for array
behaviour at any point.

I don't have any ideas about easy ways to improve singsub.  It looks
a potential minefield.

pws