From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 30 Jan 2012 05:50:44 GMT
Subject: Re: [PATCH 1/3] completion: be nicer with zsh
Message-ID: <7v4nvdeo23.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>

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>"

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).

Note that I am not suggesting to rewrite the existing ": ${var:=val}" with
"echo ${var:val} >/dev/null" at all. Even if "echo >/dev/null" makes it
work as expected, your rewrite to protect it with an explicit conditional
e.g. "test -n ${foo:-} || foo=$(bar)" would be a lot better than funny
construct like "echo >/dev/null ${foo:=$(bar)", because it is not an
established shell idiom to use default assignment with anything but ":".

Thanks.