Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
>> I find that what Jonathan gave you helps them much better:
>> ...
>> fn () {
>> var='one two'
>> printf '%s\n' $var
>> }
>> x=$(fn)
>> : ${y=$(fn)}
>>
>> printing "$x" results in two lines as expected, but printing "$y" results
>> in a single line because $var is expanded as a single word when evaluating
>> fn to compute y.
>>
>> So avoid the construct, and use an explicit 'test -n "$foo" || foo=$(bar)'
>> instead.
>>
>> So I'll take the first two lines of the message (good bits), and simplify
>> the "This fixes a bug tht caused..." from the last paragraph (or perhaps
>> even drop it).
>
> I'm not sure about it, because this relies on knowledge of how printf
> works, and it's not used that often; an example with 'for' would be
> much more clear IMO.
Meaning, replace the fn() definition with something like:
fn () {
var='one two'
for v in $var
do
echo "$v"
done
}
I can see that may make the issue easier to see; as you pointed out, it
requires no implicit knowledge that printf "loops" over the arguments
and applies the format string as manu times as needed to eat them.
Let me update the log message before I merge it to 'next'.
My main point was to illustrate the problematic pattern for people who
write for bash, not for zsh, and that does not change with the above
improvement, though ;-).
--
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