On Tue, Nov 2, 2010 at 09:33, Johannes Sixt <j.sixt@xxxxxxxxxxxxx> wrote:
> Am 10/31/2010 12:34, schrieb Ãvar ArnfjÃrà Bjarmason:
>> Change eval_gettext(1) in git-sh-i18n.sh to use a modified version of
>> gettext's envsubst(1) program, instead of using a clever (but broken)
>> printf + eval + printf trick.
>>
>> Our previous fallback would incorrectly handle cases where the
>> variable being interpolated contained spaces. E.g.:
>>
>> Â Â cmd="git foo"; eval_gettext "command: \$cmd"
>>
>> Would emit "command: gitfoo", instead of the correct "command: git
>> foo". This happened with a message in git-am.sh that used the $cmdline
>> variable.
>>
>> To work around this, and to improve our variable expansion behavior
>> (eval has security issues) I've imported a stripped-down version of
>> gettext's envsubst(1) program.
>
> Would this help the case mentioned above at all? To pass the value of
> 'cmd' to envsubst, you have to export it. But the code snippet above
> doesn't do that.
Right, I had a major brainfart. GNU gettext.sh actually works like:
eval_gettext () {
gettext "$1" | (export PATH `envsubst --variables "$1"`; envsubst "$1")
}
So I need to re-make this patch to support --variables.
> Wouldn't it be much simpler to dodge variable substitutions in the
> translated string entirely by rewriting such texts as (e.g.)
>
> Â Â Â Âgettext_printf "command: %s\n" "$cmd"
>
> and use printf in the implementation. I don't know how compatible you can
> make this with existing gettext implementations, though.
Using named variables is easier to use, and works drop-in with the GNU gettext
way of doing things. Once I implement --variables (or rather,
un-un-implement them)
it'll just work.
Thanks for the review, and for spotting this sillyness.
--
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