Re: [PATCH v6 2/2] mergetools: add winmerge as a builtin tool

[Johannes Schindelin <johannes.schindelin@gmx.de>]

Hi Junio,

On 2015-05-20 23:00, Junio C Hamano wrote:
> Sebastian Schuberth <sschuberth@gmail.com> writes:
> 
>> On Wed, May 20, 2015 at 10:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> David Aguilar <davvid@gmail.com> writes:
>>>
>>>> +     for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
>>>> +             cut -d '=' -f 2- | sort -u)
>>>
>>> Is the final "sort" really desired?  I am wondering if there are
>>> fixed precedence/preference order among variants of %PROGRAMFILES%
>>> environment variables that the users on the platform are expected
>>> to stick to, but the "sort" is sorting by the absolute pathnames of
>>> where these things are, which may not reflect that order.
>>
>> I did add the sort (and -u) by intention, to ensure that "C:\Program
>> Files" (which is what %PROGRAMFILES% expands to by default) comes
>> before "C:\Program Files (x86)" (which is what %PROGRAMFILES(X86)%
>> expands to by default), so that programs of the OS-native bitness are
>> preferred.
> 
> Yuck.  So even though %PROGRAMFILES% and %PROGRAMFILES(X86)% look as
> if they are variables that can point at arbitrary places, they in
> reality don't?  Otherwise %PROGRAMFILES% may point at D:\Program
> while %PROGRAMFILES(X86)% may piont at C:\X86 and the latter would
> sort before the former, which would defeat that "logic".

Well, you are correct, theoretically an administrator could set the registry values (which are the source of the environment variables in question) of the `ProgramFilesDir` key in both

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion

and

HKEY_LOCAL_MACHINE\Software\WOW64\Microsoft\Windows\CurrentVersion

to wildly different locations as you outlined. However, it is not supported by Microsoft to change those locations via the registry:

https://support.microsoft.com/en-us/kb/933700

Ciao,
Dscho