bug#36270: executable-find does not find shell commands on MSYS2

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 18 Jun 2019 22:49:33 +0200
> Cc: Glenn Morris <rgm@gnu.org>, 36270@debbugs.gnu.org
> 
> On Tue, Jun 18, 2019 at 6:51 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > We want to declare a file "executable" only if it can be invoked by _all_
> > possible means of running an executable file.
> 
> Sure. But let's perhaps agree that there's something to be said for
> files that are "almost executable".

Kids down here have a saying: "almost doesn't count" ;-)

> shell-command and variants are used (counting *very* roughly) about
> 150 times in the elisp sources, vs. ~300 invocations of
> call-process.

Exactly.  So what would be the point of having a general-purpose API
return files that can be useful only with some methods of running a
program?  It will only cause confusion and bug reports.

> > We could
> > make the situation a tad better if we add support for the PATHEXT
> > environment variable, as suggested in bug#7784, patches welcome.
> 
> I've read the bug thread. What exactly does mean to "add support for
> the PATHEXT environment variable"? Making file-executable-p take it
> into account?

That's one part, but it isn't the most important (nor the hardest)
part.

> Are files in the path with one of PATHEXT extensions runnable with
> call-process?

No, PATHEXT is consulted by cmd.exe and AFAIK also the ShellExecute
API.  So to support that, we will need to change sys_spawnve and/or
cmdproxy to detect an extension that appears in PATHEXT, and then
either invoke through cmdproxy or use ShellExecute instead of
CreateProcess.  And this is the more complex part of the job.

> I stumbled upon this because I was trying to understand failures in
> vc-tests.el on Windows, and the reason is that it calls call-process
> to run some shell scripts, like ci. I'd like to fix that and run the
> tests, but I haven't really stared at it long enough to know if
> there's any non-ugly fix.

One non-ugly fix is to use RCS from the ezwinports site.  The binaries
there are 32-bit, but I don't think it will make any difference.