Re: [PATCH 1/3] completion: be nicer with zsh

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, Jan 30, 2012 at 7:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Avoiding zsh's bug that cannot use conditional assignment on the no-op
>> colon command (if the bug is really that; it is somewhat hard to imagine
>> if the bug exists only for colon command, though) *is* by itself a good
>> justification for this change, even though the resulting code is harder to
>> read for people who are used to read shell scripts.
>
> Just from my curiosity, I am wondering what zsh does when given these:
>
>        bar () { echo "frotz nitfol xyzzy" }
>
>        unset foo; : ${foo:=$(bar)}; echo "<$?,$foo>"
>        unset foo; true ${foo:=$(bar)}; echo "<$?,$foo>"
>        unset foo; echo >/dev/null ${foo:=$(bar)}; echo "<$?,$foo>"

<0,frotz nitfol xyzzy>
<0,frotz nitfol xyzzy>
<0,frotz nitfol xyzzy>

And that's _without_ bash emulation.

BTW. That code didn't work for me in bash (though it did in zsh), I
had to add a semicolon:

 bar () { echo "frotz nitfol xyzzy" ;}

> The first one is exactly your "And yet another bug in zsh[1] causes a
> mismatch; zsh seems to have problem emulating wordspliting, but only when
> the ':' command is involved.", so we already know it "seems to have
> problem emulating word-splitting" (by the way, can we replace that with
> exact description of faulty symptom? e.g. "does not split words at $IFS"
> might be what you meant but still when we are assigning the result to a
> single variable, it is unclear how that matters).

That's not the problem, the problem is that this doesn't work in zsh:

array="a b c"
for i in $array; do
 echo $i
done

The result is "a b c". Unless sh emulation is on. This is the correct
way in zsh:

array="a b c"
for i in ${=array}; do
 echo $i
done

But this behavior can be controlled with SH_WORD_SPLIT.

Anyway, as I said, the problem is that the ':' have some problems, and
sh emulation seems to be turned off inside such command, or at least
SH_WORD_SPLIT was reset in my tests.

-- 
Felipe Contreras