On 4/30/24 6:44 AM, Bruno Haible wrote:
> Collin: Before you just apply this patch, two notes:
> * The patch is a pessimization on Unix systems, since executing with
> shell=True is slower than without.
> * We have basically three ways to deal with this (that I can see):
> a) Update the requirements and say that a Cygwin environment with a
> Cygwin-based Python build is required. (I tested that; so, we know
> that works.)
> b) Change the gnulib-tool entry-point script to prefer the shell-based
> implementation if the host OS, as viewed from Python, is native
> Windows (not Cygwin).
> c) Port gnulib-tool.py to native Windows.
> Your choice.
Ideally, it would probably be best to get gnulib-tool.py to work on
Windows. Since Python should do all the heavy lifting in that area.
However, you mentioned previously that it has it's own issues with
Autotools and such. Since it isn't free, I assume that anything there
is "best effort" for the most part.
You make a good point about shell=True being slower. I wonder if it is
even necessary here. When I see this error message:
OSError: [WinError 193] %1 is not a valid Win32 application
I assume that windows doesn't do anything about the '#!/bin/sh' line.
Maybe placing the shell as argv[0] in sp.run would fix it? I'm not too
sure where that is typically installed on Windows though...
Collin
