patchi18n: disable i18n for shell scripts if NO_GETTEXT defined

Otherwise the i18n is used in the scripts even with NO_GETTEXT set. It is very unexpected.

---

I usually disable i18n on my working systems as they are generally very out-of-date and not supported by any sane developer. In particular the gettext provided with this (very old) Cygwin distribution is fubar and never produces any output.

 Makefile       |    1 +
 git-sh-i18n.sh |    4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

Alex Riesen <raa.lkml@gmail.com> writes:

Thanks for spotting. I agree that we should honor NO_GETTEXT here.

But the result of the patch looks almost unreadable. could we restructure the script like this instead?

        # Decide what to do...
        GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
	if test -n "@@NO_GETTEXT@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
	then
		: no probing necessary
        elif test -n "$GIT_GETTEXT_POISON"
        then
                GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
        elif type gettext.sh >/dev/null 2>&1
        then
                GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
        elif test "$(gettext -h 2>&1)" = "-h"
        then
                GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
        fi
        export GIT_INTERNAL_GETTEXT_SH_SCHEME

        # ... and then carry out the decision
        case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
        gnu)
                ... gnu definition here ...
                ;;
        solaris)
                ... solaris cdefinition here ...
                ;;
        poison)
                ... poison cdefinition here ...
                ;;
        *)
                ... fallthru definition here ...
                ;;
        esac

On Tue, Jan 17, 2012 at 20:08, Junio C Hamano <gitster@pobox.com> wrote:

Oh, it is much nicer indeed. I shall redo the patch as soon as I get off this crappy winxp computer.

Otherwise the i18n is used in the scripts even with NO_GETTEXT set. It is very unexpected.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>

---

Junio C Hamano, Tue, Jan 17, 2012 20:08:34 +0100:

...

Done. I simplified the commentary on "poison" a little.

 Makefile       |    1 +
 git-sh-i18n.sh |  102 +++++++++++++++++++++++++++-----------------------------
 2 files changed, 50 insertions(+), 53 deletions(-)

Hi,

Alex Riesen wrote:

Sounds like a good idea.  Quick comments:

[...]

I like the unindenting.  Alas, I get

	1: test: type: unexpected operator

I suspect this should just say "elif type gettext.sh >/dev/null 2>&1".

The rest looks good.  Thanks for writing it.

On Thu, Jan 19, 2012 at 01:12, Jonathan Nieder <jrnieder@gmail.com> wrote:

Indeed. Copy-paste error. I wonder why I didn't notice it... Yes, ran the tests, both with and without NO_GETTEXT.

Was Junios idea, I just liked it.

On Tue, Jan 17, 2012 at 14:42, Alex Riesen <raa.lkml@gmail.com> wrote:

So the reason it's like that is that I was assuming that gettext.sh wouldn't be FUBAR anywhere, but the translations shouldn't kick in since we haven't installed them during "make install".

But I wonder if this negatively affects some systems, now we now:

 * Don't use gettext.sh, which means that we're using our fallback
   shell function instead of the binary gettext(1), which is probably
   faster.

 * Use our own eval_gettext() instead of using the system one, which
   uses the GNU binary which is more likely to be in the FS cache
   already since other programs are probably using it.

Which is why I didn't do something like this to begin with.

On Wed, Jan 18, 2012 at 16:22, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Well, if I say NO_GETTEXT, I kind of want none of local gettext, whether it works, or not.

On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:

That's not what NO_GETTEXT means, and not what it *should* mean. It means that your output won't be translated, but we might still make use of a locally installed library to provide the gettext() and eval_gettext() functions.

This approach has worked everywhere so far (Linux, OSX, *BSD etc.), and you want to change *everywhere* because you have some completely broken Cygwin install.

How did you even get that install? Is it a known issue? Some ancient now-fixed bug? What version of Cygwin / gettext etc.

Now I'm not saying that we shouldn't fix this, I just don't think that this is the right way to go about it.

Now I haven't done exhaustive tests but this is the sort of slowdown we might be looking at on Linux for output, both with warm cache:

    $ cat our-eval_gettext.sh
    #!/bin/bash

    eval_gettext () {
            printf "%s" "$1" | (
                    export PATH $(git sh-i18n--envsubst --variables "$1");
                    git sh-i18n--envsubst "$1"
            )
    }
    for i in {1..1000}
    do
        some_variable="for speed"
        eval_gettext "benchmark this \$some_variable"
    done
    $ time bash our-eval_gettext.sh >/dev/null

    real    0m3.336s
    user    0m0.052s
    sys     0m0.128s

Compared to using the system eval_gettext, which for me is much faster:

    $ cat system-eval_gettext.sh
    #!/bin/bash

    . gettext.sh
    for i in {1..1000}
    do
        some_variable="for speed"
        eval_gettext "benchmark this \$some_variable"
    done
    $ time bash system-eval_gettext.sh >/dev/null

    real    0m1.671s
    user    0m0.048s
    sys     0m0.140s

And then we have the gettext() function itself:

    $ cat our-gettext.sh
    #!/bin/bash

    gettext () {
            printf "%s" "$1"
    }

    for i in {1..1000}
    do
        gettext "benchmark this"
    done
    $ cat system-gettext.sh
    #!/bin/bash

    for i in {1..1000}
    do
        gettext "benchmark this"
    done

Where our fallback is faster, because printf() is a bash built-in:

    $ time bash system-gettext.sh >/dev/null

    real    0m0.534s
    user    0m0.016s
    sys     0m0.084s
    $ time bash our-gettext.sh >/dev/null

    real    0m0.018s
    user    0m0.016s
    sys     0m0.000s

Anyway speed is the least of the issues here, it's not like we're very constrained by spewing out gettext output.

I just think we should consider portability more carefully than "it doesn't work on one obscure setup, let's change it everywhere", when actually it's working just fine in most places.

I think a better fix would be to add probes for whether the system functions actually work in the autoconf script.

I'd also love to be able to use C macros in the git-*.sh scripts, it would make the code in git-sh-i18n.sh much nicer since we can determine what functions we want at compile time.

Another option would be to pipe our shellscripts through some pre-processor that would completely remove the gettext and eval_gettext calls. Then we'd be doing the same thing we're doing on the C-Level, and we wouldn't have the previously cited command-call overhead or Win32.

But in summary: We shouldn't be *always* using fallback functions whether they're the C stuff in compat/* or the gettext fallbacks in git-sh-i18n.sh just because there's some version out there of the system-supplied functions that's broken.

It makes sense to prefer the system functions by default in both cases, but when the OS one can be broken or lacking we can just add probes or Makefile options like we do for fnmatch() with the NO_FNMATCH_CASEFOLD switch.

Ævar Arnfjörð Bjarmason wrote:

I thought NO_GETTEXT meant either "I'm aware that there is this new translation feature, and it may or may not be useful to me some day, but no thanks for now, since I cannot tolerate the possibility of regressions" (i.e., opting out of a new feature) or "my platform does not have suitable gettext infrastructure so please do not use it" (i.e., reducing build-time dependencies by making some optional).

"I don't want localized messages" is spelled as "LC_MESSAGES=C; export LC_MESSAGES", not as "make NO_GETTEXT=YesPlease".

I guess I am wondering, does the approach in Alex's patch have the potential to cause actual problems? If it doesn't, I don't see what there is to complain about.

Hope that helps, Jonathan

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

You are right.

In the current approach we take for shell scripts, we cannot have "No i18n whatsoever and messages are emit with printf and echo". We always have to go through gettext/eval_gettext even though they may be an implementation that does not do i18n at all.

I think we judged that it is OK not to worry about the performance of message generation, back when we decided to take the current approach.

So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is that correct?

If that is the case, should we do something like

	LANG=C LC_ALL=C
        export LANG LC_ALL

in our shell scripts, when building for NO_GETTEXT target?

Am 1/19/2012 1:17, schrieb Junio C Hamano:

Sorry to disagree: We have, e.g., NO_MMAP, and I can set it to request that some alternative is used, even if I have a working mmap(). The option name "NO_GETTEXT" is in exactly the same spirit.

Just like we go through _() in C code, even though there may be an implementation that does not do i18n at all, right?

gettext/eval_gettext annotations are the shell equivalent of _() annotations in C code, aren't they? Neither go away just by defining NO_GETTEXT. It is just a quality-of-implementation issue that those annotations have as little overhead as possible if NO_GETTEXT is defined. In C, it is easy, in shell code it may be more involved.

-- Hannes

Johannes Sixt <j.sixt@viscovery.net> writes:

Yes, just like that. The small detail that _() can be #define'd out to empty while gettext/eval_gettext cannot be made to be no-impact like that does not really matter.

Correct.

On Thu, Jan 19, 2012 at 19:30, Junio C Hamano <gitster@pobox.com> wrote:

To elaborate, the C code can:

 * Use the system gettext library to get translations.

 * Use the system gettext library, but effectively be pass-through
   because the user has the C locale.

 * Use our fallback functions which in any modern compiler will be
   optimized out.

However with the shell code we can:

 1. Be using the system gettext & eval_gettext to get translations.

 2. Be using the system gettext & eval_gettext as pass-through, either
    because we don't have translations since we've installed with
    NO_GETTEXT=YesPlease, or because we're in the C locale.

 3. Haven't detected that gettext.sh etc. exists, so we have to provide
    our own fallbacks.

The proposed patch would move all users of NO_GETTEXT=YesPlease to #3, even though on most platforms we don't need to define our own dummy fallbacks since the system already provides them.

I don't particularly like it because I'd rather use the OS vendor's implementation if possible, even for fallback.

However it being broken is also unacceptable, but I think the way forward is to detect the breakage either at compile time or at runtime, to that end Alex could you provide us with the output from the following commands on the offending system where this is broken:

    $ type gettext.sh
    $ gettext.sh --version
    $ gettext -h
    $ gettext "some test text"
    $ . gettext.sh
    eval_gettext
    $ variable=value eval_gettext "some \$variable"

Then how the eval_gettext function is defined:

    $ type eval_gettext
    eval_gettext is a function
    eval_gettext ()
    {
        gettext "$1" | ( export PATH `envsubst --variables "$1"`;
        envsubst "$1" )
    }

And then a --version for whatever programs that function uses, e.g. here:

    $ envsubst --version

Once we know how it breaks we can e.g. add configure tests for checking whether we can use the system's gettext library for the fallbacks.

Could you also run the git test suite as described in t/README? I'd expect a lot of the i18n tests to fail, but it would be curious to see which ones exactly.

On Fri, Jan 20, 2012 at 10:50, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Well, I dunno. I wouldn't trust anything to this particular "OS vendoer".

Better at runtime, unless the packager explicitly stated they don't want any of this.

gettext.sh is /usr/bin/gettext.sh

/usr/bin/gettext.sh (GNU gettext-runtime) 0.18.1 Copyright (C) 2003-2007 Free Software Foundation, Inc. License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Bruno Haible

Nothing. Exit code 127.

Nothing. Exit code 127.

Nothing. Exit code 0.

Nothing. Exit code 127.

Nothing. Exit code 127.

eval_gettext is a function
eval_gettext ()
{
    gettext "$1" | ( export PATH `envsubst --variables "$1"`;
    envsubst "$1" )
}

Nothing. Exit code 127.

The exit code seems to be a good enough test here, but testing some output (or even translation) would be safer.

I believe gettext (the binary) just doesn't start at all here. Maybe some Cygwin library wrong or missing library. Happens all the time here, as we have different Cygwin installations depending on the currently used toolchain. QNX Momentics, in particular. Different versions of them, and it is too cumbersome to keep them apart.

Yes, they do. Can't run them on this problematic system, because they tend to crash it, if run for an undetermined while. On the other system, which can run them, gettext works (it is an older Cygwin installation), so almost all tests pass (some still don't, but for reasons unrelated). Strangely enough, the problematic system can build. So I don't copy the git binaries, they are actually built on that system.

Even though we can load gettext.sh the gettext(1) and eval_gettext functions it provides might be completely broken. This reportedly happens on some Cygwin installations where we can load gettext.sh, but gettext and eval_gettext both return exit code 127 and no output.

The reason we're trying to load gettext.sh (or the equivalent Solaris implementation) at all is so we don't have to provide our own fallback implementation if the OS already has one installed, but because we didn't test whether it actually worked under GNU gettext we might end up with broken functions.

Change the detection in git-sh-i18n so that it tests that the output of "gettext test" produces "test", on Solaris we already test that "gettext -h" produces "-h", so we were already guarded against the same sort of failure there.

Reported-by: Alex Riesen <raa.lkml@gmail.com>
---
Here's a minimal patch to git-sh-i18n that should make things work on
Cygwin and any other platforms with broken gettext functions while
also using the OS-provided functions if they work.

I've added a new t0201-gettext-fallbacks-broken-gettext.sh test that tests this. This required a small change in lib-gettext.sh so I wouldn't load test-lib.sh twice.

Note that there's already a t0201* test in the repo. Maybe we want to increment all the gettext test numbers by one to make room for it?

As an aside I'm really not a big fan of having hardcoded numbers in the test files like this. We don't care about the order of execution here.

 git-sh-i18n.sh                              |    2 +-
 t/lib-gettext.sh                            |    7 +++++-
 t/t0201-gettext-fallbacks-broken-gettext.sh |   28 +++++++++++++++++++++++++++
 3 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100755 t/t0201-gettext-fallbacks-broken-gettext.sh

On Fri, Jan 20, 2012 at 13:49, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

FWIW, I confirm it works (which is quite obvious).

Just for giggles, I even risked running the tests and, of course, crashed that piece of junk with broken Cygwin installation. Please don't ask me to do that again :) restarting it is PITA as well.

Just for future reference to all poor Cygwin users:

I also left NO_GETTEXT in the config.mak. This, BTW, explains why git works, while gettext binary does not: one .dll dependency less.

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

We do not care the order but we do care about the uniqueness in parallel test execution.

It does appear that we need a bit better preprocessing of git-sh-i18n at the compile time now. How about applying the restructuring shown in the patch by Alex (without the @@NO_GETTEXT@@ bit) first without changing any logic, then try making the "First decide what scheme to use" part lighter weight by replacing the runtime "type gettext.sh" and such checks with some preprocessing?

IOW, the first step would look like the attached patch, and then we can replace the entire "First decide" part if/elif/fi chain with just this:

	# The scheme to use
        : ${GIT_INTERNAL_GETTEXT_SH_SCHEME:=@@GETTEXT_SH_SCHEME@@}

so that t/lib-gettext.sh can define and export GIT_INTERNAL_GETTEXT_SH to always get what it wants to test (fallthrough?). At build time, instead of, or in addition to, the $(cmd_munge_script), we could replace the single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to use to hardcode the decision we make at the compile time.

Hmm?

 git-sh-i18n.sh |  103 +++++++++++++++++++++++++++-----------------------------
 1 files changed, 50 insertions(+), 53 deletions(-)

On Fri, Jan 20, 2012 at 21:00, Junio C Hamano <gitster@pobox.com> wrote:

I can imagine a Solaris system being upgraded to GNU gettext _after_ Git installation. Hardcoding the decision might break git scripts then.

Alex Riesen <raa.lkml@gmail.com> writes:

Just like you would break http transport by removing libcurl after installing Git? What else is new?

On Fri, Jan 20, 2012 at 21:21, Junio C Hamano <gitster@pobox.com> wrote:

Removing - yes, upgrading it - very unlikely. Besides, the current version wont have problems with such an upgrade.

Alex Riesen <raa.lkml@gmail.com> writes:

Yes, but at what cost?

On Fri, Jan 20, 2012 at 21:26, Junio C Hamano <gitster@pobox.com> wrote:

A fixed number of "fork and exec" for every executed ". git-sh-i18n" line? The overhead might be considered negligible...

Er. Am I missing something very obvious? (not obvious to me, yet)

Alex Riesen <raa.lkml@gmail.com> writes:

Interesting.

    $ wonbsubst --version; echo $?
    bash: wonbsubst: command not found
    127

Perhaps your distro lacks a necessary package dependencies between gettext and envsubst?

Aha.

I guess we either leave it broken for broken installation or add an extra "MY_GETTEXT_IS_BROKEN" option; in either way, it does not sound like a serious enough issue that is widespread to be urgently fixed during the feature freeze.

On Fri, Jan 20, 2012 at 20:35, Junio C Hamano <gitster@pobox.com> wrote:

Ævar already posted a very cute little fix for this, which looks pretty minimal and is very obvious.

P.S. Sorry for html mail before (tried to use the Android Gmail client).

On Thu, Jan 19, 2012 at 01:17, Junio C Hamano <gitster@pobox.com> wrote:

I think yes.

Just for the record: gettext here stays broken with LANG and LC_ALL set to C. But the locale-dependent formatting in C functions will change. Wont be a problem here, though. The named formatting is broken, too: strftime, for instance, always formats in C locale.

On Thu, Jan 19, 2012 at 00:18, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

I would never guess all that by its name: NO_GETTEXT. I wanted to say: there is no gettext in this installation, don't even try it.

Just as I said.

It is very likely. Or probably just a one installation problem: the problem is not consistently everywhere here. Some installations work (if slow).

No idea. The person or persons who did this to me have no idea either.

And I agree.

Yes, and I personally shall welcome a chance to insult the local IT by suggesting BROKEN_SH_GETTEXT. Not that they get the point...

Some systems have gettext.sh (GNU gettext) installed, but it is either broken or misconfigured in such a way so its output is not usable. For instance, on this particular system, a Cygwin installations gettext produces no output whatsoever.

In case the users of these systems are unable or not interested in fixing them, setting the new Makefile switch should help:

    USE_FALLTHROUGH_GETTEXT_SCHEME=yes

This will replace the translation routines with fallthrough versions, which currently used only for regression testing.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---

Alex Riesen, Thu, Jan 19, 2012 10:13:20 +0100:

I believe this patch does just that. It is certainly enough for my purposes. The copy-paste error noticed by Jonathan is also fixed, thanks! I didn't add the tracking of the switch in GIT-BUILD-OPTIONS: didn't found how to do it quickly enough in this time of evening, and gave up, thinking that no one sane would need to set the option anyway. So at the moment a "make clean" needed when changing it.

 Makefile       |    4 ++
 git-sh-i18n.sh |  102 +++++++++++++++++++++++++++-----------------------------
 2 files changed, 53 insertions(+), 53 deletions(-)

Alex Riesen <raa.lkml@gmail.com> writes:

I'll split this into two, the first one only to restructure the code and the guts of this one that avoids the autodetection.

Also I'd rename this so that:

	$ make USE_GETTEXT_SCHEME=fallthrough
	$ make USE_GETTEXT_SCHEME=gnu

could be used to avoid extra and unnecessary runtime overhead when the person building git knows what is on the system.

Instead of having a single long and complex chain of commands to decide what to do and carry out the decision, split the code so that we first decide which scheme to use, and in the second section define what exactly is done by the chosen scheme. It makes the code much easier to follow and update.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-sh-i18n.sh |  103 +++++++++++++++++++++++++++-----------------------------
 1 files changed, 50 insertions(+), 53 deletions(-)

From: Alex Riesen <raa.lkml@gmail.com>

Some systems have gettext.sh (GNU gettext) installed, but it is either broken or misconfigured in such a way so its output is not usable. In case the users of these systems are unable or not interested in fixing them, setting the new Makefile switch should help:

    make USE_GETTEXT_SCHEME=fallthrough

This will replace the translation routines with fallthrough versions, that does not use gettext from the platform.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Makefile       |    4 ++++
 git-sh-i18n.sh |    5 ++++-
 2 files changed, 8 insertions(+), 1 deletions(-)

Junio C Hamano wrote:

Nice implementation. I still don't understand why NO_GETTEXT=YesPlease should not imply this. Is it to ensure the GETTEXT_SCHEME=gnu mode gets more testing?

Here's a patch to consider squashing in that makes the option take effect if it changes between builds.

Jonathan Nieder <jrnieder@gmail.com> writes:

Should be easy to do so, like this?

Junio C Hamano wrote:

Yep, that would make my worries about intuitive behavior evaporate. :) (Maybe "USE_GETTEXT_SCHEME ?= fallthrough" to make it easier to override in config.mak.)

Thanks. I also would not actually mind the behavior without that tweak, as long as it's explained somewhere.

Ciao, Jonathan

From: Junio C Hamano <gitster@pobox.com>

When NO_GETTEXT is set, even if a usable installed gettext.sh is detected to be present, it can only help to use git's simple fallback stub implementations of gettext and eval_gettext for shell scripts instead. That way:

 1) we avoid the complication of autodetection of gettext.sh support
    at runtime;

 2) in particular, if the operating system provides gettext.sh but
    it is unusable, we will not be tricked into trying to use it.

So this patch makes USE_GETTEXT_SCHEME default to fallthrough when NO_GETTEXT is set. This is only a default so the operator can set USE_GETTEXT_SCHEME=gnu or ...=gettext_without_eval_gettext to try the other schemes.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:

Probably too late to be useful, but here's a patch with commit message implementing the same.

 Makefile |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

On Tue, Jan 24, 2012 at 01:31, Jonathan Nieder <jrnieder@gmail.com> wrote:

We already use GNU make features (+=), so this can be just

USE_GETTEXT_SCHEME ?= fallthrough

I think...

On Mon, Jan 23, 2012 at 23:12, Jonathan Nieder <jrnieder@gmail.com> wrote:

I was the only one with an objection to doing that. The main (and I admit, at least slightly irrational) reason being that I simply don't like using fallback functions when the system supplies us with perfectly good functions we can use instead.

It means we're less likely to share code / fixes / eyeballs / cache with other programs. I.e. by using envsubst(1) instead of git-sh-i18n--envsubst--variables(1).

Ironically this is all my fault by naming the option for turning off translations NO_GETTEXT. What it should be called is DO_NOT_TRANSLATE_OUTPUT, but since we *need* shell functions to output anything it might have used a system gettext library to do that, NO_GETTEXT should have been "I don't have any gettext library, please supply some fallbacks".

Which would have meant that for people who simply don't want translated output we'd be using the maintained by upstream envsubst(1) instead of the doomed to bitrot forever hack I ripped out of some old GPL2 version of GNU gettext.

Anyway in the grand scheme of things none of this really matters, these patches can all go in as far as I'm concerned. I can submit patches to improve it once the dust has settled if I still care enough.

Aside from this I think not having the ability to run a pre-processor on the shellscripts results in some really ugly workarounds. This stuff would be much nicer if we could just generate git-sh-i18n.sh at compile time depending on some autoconf tests or Makefile options.

And by hacking up a pre-processor that just searches/replaces all the gettext/eval_gettext calls out of the shell code we could sidestep this whole issue and there wouldn't be any need for fallback functions, ever. This would also result in a real improvement on Windows where exec overhead is much larger.

Like this hack, which doesn't even work, but gives you some idea of what we could do:

    #!/usr/bin/env perl
    BEGIN { $^I = ""; }

    sub unescape {
    	my $str = shift;
    	$str =~ s/\\\$/\$/gs;
    	$str;
    }

    LINE: while (defined($_ = <ARGV>)) {
    	s["\$\(gettext "([^"]+?)"\)"]["$1"]g;
    	s["\$\(eval_gettext "([^"]+?)"\)"]['"' . unescape($1) . '"']eg;
    	s[eval_gettextln "([^"]+?)"]['echo "' . unescape($1) . '"']eg;
    	s[gettext "([^"]+?)"][printf "%s" "$1"]g;
    	s[gettextln "([^"]+?)"][echo "$1"]g;
    #	s[gettextln "([^"]+?)"][echo "$1"]g;
    #	s/foo/bar/;
    	print;

    }

When run:

    for f in $(git grep -l gettext -- *.sh); do perl replace-gettext.pl $f; done

Produces output like:

    @@ -351 +351 @@ split_patches () {
    -                       clean_abort "$(eval_gettext "Patch format
\$patch_format is not supported.")"
    +                       clean_abort "Patch format $patch_format is
not supported."
    @@ -353 +353 @@ split_patches () {
    -                       clean_abort "$(gettext "Patch format
detection failed.")"
    +                       clean_abort "Patch format detection failed."
    @@ -403 +403 @@ do
    -               die "$(gettext "-d option is no longer supported.
Do not use.")"
    +               die "-d option is no longer supported.  Do not use."
    @@ -466 +466 @@ then
    -       die "$(eval_gettext "previous rebase directory \$dotest
still exists but mbox given.")"
    +       die "previous rebase directory $dotest still exists but mbox given."

It would be relatively easy to hack up a basic POSIX shell pre-processor like this that would work on our *.sh files, thus eliminating the need for all of this fallback business.

On Mon, Jan 23, 2012 at 23:12, Jonathan Nieder <jrnieder@gmail.com> wrote:

Which actually bit me once, when I was playing with the code :)

On Mon, Jan 23, 2012 at 23:04, Junio C Hamano <gitster@pobox.com> wrote:

Amen :)

Thanks.