Junio C Hamano [off-list ref] 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.
On Mon, Jan 30, 2012 at 7:50 AM, Junio C Hamano [off-list ref] wrote:
Junio C Hamano [off-list ref] writes:
quoted
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