> From: Gavin Smith <gavinsmith0...@gmail.com> > Date: Sat, 26 Oct 2024 10:43:54 +0100 > Cc: Bruno Haible <br...@clisp.org>, pertu...@free.fr, bug-texinfo@gnu.org > > > Those errors are expected. The one about /dev/null happens because the > > Perl and executable are native, while the shell is cygwin and not a > > "native" shell such as the mingw shell that would map /dev/null to the > > native NUL. There are similar errors with path separators that are not > > mapped. There is an unknown error that cannot really be understood from > > the error log. The other are related to file name encoding. My wild > > guess is that the locale of the cygwin shell is not the same as the > > locale of the native executables and Perl. > > The question is, is it mingw (native Windows programs), or Cygwin?
MinGW programs are stand-alone native Windows executables. But the MinGW development environment includes MSYS Bash and MSYS ports of various GNU utilities, and is intended to be used in all the cases where a Posix shell and associated utilities are expected. Prominent examples include running the Unix configure scripts (and Makefile's they create, which include fragments of shell scripts), and running test suites which are based on shell scripts. Cygwin comes with its own versions of Bash and the associated utilities, but they do not cater to MinGW programs by making, behind the scenes, the few adaptations that allow running native Windows programs from a Posix environment. As a simple example, colon-separated PATH gets converted to semi-colon separated when MSYS Bash invokes a MinGW program; without that, not MinGW program could ever find executables and shared libraries by searching PATH. > If the answer is neither, but some mixture of the two, then my working > assumption is that it is a bogus setup not worth spending time on. It is a "mixture" in the above sense: the Texinfo executables are MinGW, but the development environment is not MSYS, thus it reveals problems that will not happen if using MSYS.
