Re: texinfo-5.9.90 pretest available

[Eli Zaretskii]

> Date: Thu, 26 Feb 2015 22:03:16 GMT
> From: address@hidden (Karl Berry)
> 
>     I didn't mean to change this in texi2any.pl that is installed, 
> 
> Additional ugliness and complexity merely to work around Windows
> deficiencies seems pretty undesirable to me.

I can always patch that locally, and do it forever.  It will cause
grief to others, but if we don't care about that, fine.

> Eli, groff has a bunch of #!/usr/bin/env perl scripts.
> What does mingw do with them?

Provides Windows batch-file scripts to run them, like we do in
Texinfo.

This is all a misunderstanding, primarily about how the problem
happens, and most probably also what "MinGW" really means in this
context.  Let me explain.

First, some background:

MinGW produces native Windows programs.  When the produced programs
are installed and run, it's the Windows OS running Windows programs;
there's nothing special about those programs, as far as the OS is
concerned.

Windows doesn't support the shebang method of specifying the
interpreter to run a script.  It doesn't support it at all, no matter
if it says "/bin/foo" or "/usr/bin/env/foo bar".  Windows has a
different mechanism, called "file association", to specify that in a
system-wide manner, and another mechanism that uses an environment
variable that is local to a shell instance.  However, all of these
methods are based on the file's extension, so in the case of Perl one
must have the file end in ".pl", while we install 'texi2any' without
any extensions.  In addition, not every installation of Perl on
Windows uses one of these methods, and even if they do, the user can
revert them.  IOW, this is unreliable.  So we provide Windows batch
files to DTRT, each one of which basically invokes Perl on its
namesake Perl script, e.g., there's texi2any.bat that invokes
"perl texi2any".

That being said, it's not entirely relevant to the issue at hand.  The
issue at hand is about running the test suite.  The test suite is
heavily Posix-oriented, and needs a Posix shell and utilities to run.
So for that I use MSYS, which is a Posix-like environment specifically
tailored to building and running MinGW programs.  It has its own Bash
and its own Perl, and it doesn't use the above mentioned native
Windows methods of associating files with programs.  It does support
shebang.

The problem happens when a test invokes just "../texi2any" or some
such, because MSYS doesn't seem to support "/usr/bin/env foo" kind of
shebang.  That's all there is to it: a test fails because such
invocation of a Perl script will not work on MSYS.

Groff doesn't invoke the Perl scripts like that, so the problem is
never seen there.

That is why I think the issue can be easily fixed (provided that
there's an agreement to fix it) -- it is limited to how the script is
invoked by a test script.  There are no other issues with this related
to the Windows port that we didn't already solve.

I hope this clears up the issue.