Hi Collin, > > * 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.
OK. > I assume that windows doesn't do anything about the '#!/bin/sh' line. Indeed, that is likely the explanation: All 3 programs (autoconf, autoheader, automake) start with '#!/usr/bin/perl', and while native Windows does not interpret the shebang line, the Cygwin and MSYS2 shells apparently do. > Maybe placing the shell as argv[0] in sp.run would fix it? I think that's already taken into account by the Python implementation of shell=True. Since the reporter says that this fixes the problem (and it is more future-proof than setting argv[0] to "perl"), I would do that — but on native Windows only. That is, test os.name or sys.platform first, so that we avoid a slowdown on Unix. Bruno
