From: Sebastian Schuberth <sschuberth@gmail.com>
Date: Wed, 13 May 2015 15:33:53 GMT
Subject: Re: [PATCH v2] mergetools: add winmerge as a builtin tool
Message-ID: <CAHGBnuPDSdCyVNM+Gagang1Cf9yw0Tyios45i6pnZSSzaJJC2Q@mail.gmail.com>
In-Reply-To: <3d7e3b09b89c46c39befca7564f5c1d6@www.dscho.org>

On Wed, May 13, 2015 at 5:22 PM, Johannes Schindelin
<johannes.schindelin@gmx.de> wrote:

> In my tests, "$PROGRAMFILES(X86)" did *not* work:
>
>     $ echo "$PROGRAMFILES(X86)"
>     bash: syntax error near unexpected token `('

Interesting. In both MSYS1/2 Git Bashes I get on Windows 7 64-bit:

$ echo "$PROGRAMFILES(X86)"
C:\Program Files (x86)(X86)

So it seems to resolve only the $PROGRAMFILES part and appending the
literal "(X86)". Not sure how to tell Bash that "(X86)" is part of the
variable name.

> Exactly. In my tests, "$ProgramW6432" worked, while "$PROGRAMW6432" did not.

Very odd indeed that for me it's the exact opposite.

> FWIW I think that the idea to test for a WinMerge executable of another bitness makes sense, because we can execute an executable of another bitness (unlike a .dll of another bitness).

I agree it makes sense to check for both 64-bit and 32-bit WinMerge
installations. But IMO it does not make sense to mix in the bitness of
the process requesting the environment as part of running the
mergetools/winmerge script, which is what we do by querying
"$ProgramW6432" / "$PROGRAMW6432" .

-- 
Sebastian Schuberth