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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 30, 2012, 05:50 UTC
Message-ID: <7v4nvdeo23.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7v8vkperli.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 5 quoted lines

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