Re: [PATCH v2] mergetools: add winmerge as a builtin tool
- From
Sebastian Schuberth <sschuberth@gmail.com>
- Date
- May 13, 2015, 15:33 UTC
- 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