Re: [PATCH 1/3] completion: be nicer with zsh
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Jan 30, 2012, 10:30 UTC
- Message-ID
- <CAMP44s2PsSj=mTZMtkteHnycqEXgO7YQeJzSuH9T734pFQiJMQ@mail.gmail.com>
- In-Reply-To
- <7v4nvdeo23.fsf@alter.siamese.dyndns.org>
On Mon, Jan 30, 2012 at 7:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> 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" ;}Show 7 quoted lines
> 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
doneBut 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