Re: [git-for-windows] Re: [ANNOUNCE] Git v2.16.0-rc1

> On Tue, 9 Jan 2018, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> diff --git a/t/t0021/rot13-filter.pl b/t/t0021/rot13-filter.pl
>>> index f1678851de9..470107248eb 100644
>>> --- a/t/t0021/rot13-filter.pl
>>> +++ b/t/t0021/rot13-filter.pl
>>> @@ -31,7 +31,22 @@
>>>   #
>>>   
>>>   use 5.008;
>>> -use lib (split(/:/, $ENV{GITPERLLIB}));
>>> +sub gitperllib {
>>> +...
>>> +	if ($ENV{GITPERLLIB} =~ /;/) {
>>> +		return split(/;/, $ENV{GITPERLLIB});
>>> +	}
>>> +	return split(/:/, $ENV{GITPERLLIB});
>>> +}
>>
>> This cannot be the whole story for a few reasons.
>>
>>   - In t/test-lib.sh we see this:
>>
>>     GITPERLLIB="$GIT_BUILD_DIR"/perl/blib/lib:"$GIT_BUILD_DIR"/perl/blib/arch/auto/Git
>>     export GITPERLLIB
>>
>>     If this part wants to split with ';', then the joining needs to
>>     be done with ';' to match, no?
> 
> No.
> 
> It is a lot more complicated than that. As you know, on Linux there is
> this implicit assumption that path lists are colon-separated. As a
> consequence, Cygwin does the same (because it would be too hard to port
> all those Linux/Unix projects to stop assuming colon-separated path lists,
> right?)
> 
> This is what Cygwin's Bash does (and hence the MSYS2 Bash used by Git for
> Windows, too).
> 
> Then the MSYS2 Bash calls git.exe, which is *not* an MSYS2 program, hence
> the MSYS2 runtime knows that it has to convert the path lists to Windows
> paths separated by semicolons.
> 
> The next thing happening in our case is that the Perl script is called
> from git.exe. Now, the MSYS2 runtime (implicitly spun up by the MSYS2 Perl
> interpreter) does *not* convert those path lists back to Unix-like paths
> separated by colons.

> And that's why the Unix shell script can happily construct the
> colon-separated list, and the Perl script will *still* receive the
> semicolon-separated version of it.
> 
>>   - In addition to t0021, there are similar split with colon in 0202,
>>     9000 and 9700, yet I am getting the feeling that you observed the
>>     issue only in0021, to which I do not think of a good explanation
>>     why.
> 
> Here is the good explanation: t0021 relies on a Perl package that is not
> yet installed. t0202 relies on Git::I18N, of which there is a version
> installed in Git for Windows' SDK. (I do not bother to slow down the test
> runs by the Subversion tests, I always skip all of them, that's why t9*
> does not matter to me.)