Junio C Hamano <gitster@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html