Bug in calls to perl scripts from Windows executables in TeXLive 2023?

[John Collins]

On 7/22/23 4:01 PM, Siep Kroonenberg wrote:
> ...
>>
>> Just to be clear: did you explicitly configure
>> TEXLIVE_WINDOWS_TRY_EXTERNAL_PERL = 1
>> in C:\texlive\2023\texmf.cnf?
> 
> And, for that matter, did you run our TL or the onve from msys2?


Yes, this is your TL, i.e., the native Windows version, and definitely not the 
one from msys2.  My installation of TL 2023 long predates my installation of 
MSYS2.  When I installed TL 2023, I already had installed Strawberry Perl, so 
the installation itself set  TEXLIVE_WINDOWS_TRY_EXTERNAL_PERL = 1
in C:\texlive\2023\texmf.cnf.   I did not set that myself.  According to the 
comment in that file: "% Was set to 1 if at install time a sufficiently recent 
Perl was detected."

As I mentioned in an earlier reply to you (which I forgot to copy to the 
tex-live list), my sole reason for installing msys2 was to debug a problem a 
user had reported with latexmk.

There were symptoms from unix-style file names in his bug report that indicated 
he was not using a standard Windows Perl.  I could not reproduce his problem 
until I installed MSYS2, **and** put its binary directory in my PATH ahead of 
the Strawberry Perl directory.   After that I saw the same phenomenon as the 
user did, and that's what I described in my post.

I'll need to check this explicitly with the user, but I suspect his 
installation of MSYS2 on his computer was a merely a side effect of the 
installation  of some other software that he needed and that uses MSYS2.

After Karl's explanation about runscript.tlu, and some further tests of my own, 
I think the problem is downstream from TL; it may even be in how MSYS's perl 
parses its command line.

Best,
John Collins