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

[John Collins]

On 7/21/23 6:13 PM, Karl Berry wrote:
> John - the wrapper builds the command line as an array of strings
> (adding double quotes around args with spaces) and calls the Lua
> function os.spawn on it. It doesn't know what shell interpreter will be
> invoked. I don't see how it can do anything differently. Here's the
> source:
> https://tug.org/svn/texlive/trunk/Build/source/texk/texlive/windows_wrapper/runscript.tlu?revision=66266&view=markup
> (line 921 is the eventual call)
> 
> So maybe this is somehow about what os.spawn() does on MSYS?
> Sorry, I can't guess further ... --best, karl.

Yes.  Given the code in runscript.tlu, I don't see any other way to get the 
behavior I see.  Until os.spawn is called, there is nothing relevant that 
changes depending on the perl interpreter that is used.  Certainly there's 
nothing that has any indication of which kind of executable the invoked 
perl.exe is.

So I think we should conclude that the behavior I am seeing is caused by some 
anomalous behavior in the combination of os.spawn() and the particular Windows 
system call(s) it uses, in a way that depends on the type of .exe file that is 
run. (Possibly, in addition, there's some odd behavior of MSYS's perl, but I 
think that unlikely, since I don't see problems when I invoke it directly.)

The conclusion about the source of the problems is supported by the experiments 
I've done (e.g., running pdfcrop with strange arguments and looking at the 
error messages from pdfcrop and runscript).

Best,
John