git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH 1/5] gettext: fix bug in git-sh-i18n's eval_gettext() by using envsubst(1)

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Nov 8, 2010, 22:39 UTC
Message-ID
<AANLkTimjRwSxkemMffASvHCxK009b1fnvNRs05_T_1DF@mail.gmail.com>
In-Reply-To
<4CCFCCC8.7080603@viscovery.net>
On Tue, Nov 2, 2010 at 09:33, Johannes Sixt <j.sixt@viscovery.net> wrote:
Show 21 quoted lines
> 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.
Show 7 quoted lines
> 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.
Previous: Johannes SixtNext: Johannes Sixt
Message 10 of 27 in “Buglet in i18n?”
  1. Johannes SixtOct 22, 2010
  2. Ævar Arnfjörð BjarmasonOct 22, 2010
  3. Jonathan NiederOct 22, 2010
  4. Ævar Arnfjörð BjarmasonOct 23, 2010
  5. Johannes SixtOct 22, 2010
  6. Ævar Arnfjörð BjarmasonOct 30, 2010
  7. 0/5 ab/i18n: Things I'll add in the next iterationÆvar Arnfjörð Bjarmason, Oct 31, 2010
  8. 1/5 gettext: fix bug in git-sh-i18n's eval_gettext() by using envsubst(1)Ævar Arnfjörð Bjarmason, Oct 31, 2010
  9. Johannes SixtNov 2, 2010
  10. Ævar Arnfjörð BjarmasonNov 8, 2010
  11. Johannes SixtNov 9, 2010
  12. Ævar Arnfjörð BjarmasonNov 9, 2010
  13. Johannes SixtNov 9, 2010
  14. Ævar Arnfjörð BjarmasonNov 9, 2010
  15. Johannes SixtNov 9, 2010
  16. Erik Faye-LundNov 9, 2010
  17. Ævar Arnfjörð BjarmasonNov 9, 2010
  18. Johannes SixtNov 9, 2010
  19. Ævar Arnfjörð BjarmasonNov 9, 2010
  20. Johannes SixtNov 9, 2010
  21. Ævar Arnfjörð BjarmasonNov 9, 2010
  22. Johannes SixtNov 9, 2010
  23. Ævar Arnfjörð BjarmasonNov 9, 2010
  24. 2/5 gettextize: git-clone: !fixup "basic messages"Ævar Arnfjörð Bjarmason, Oct 31, 2010
  25. 3/5 gettextize: git-init: !fixup "basic messages"Ævar Arnfjörð Bjarmason, Oct 31, 2010
  26. 4/5 gettextize: git-revert: !fixup "Your local changes"Ævar Arnfjörð Bjarmason, Oct 31, 2010
  27. 5/5 gettextize: git-merge: !fixup "basic messages"Ævar Arnfjörð Bjarmason, Oct 31, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.