How does a mingw-w64-x86_64- binary decide to do plain CreateProcess or something else, when invoked?

[janko-jj]

To illustrate the question, I have ninja.exe from here:

mingw-w64-x86_64-ninja-1.12.1-1-any.pkg.tar.zst

And I've created an empty file 'aaa' and the file build.ninja with the content:

rule all
   command = mv aaa bbb

build a: all

If I go to cmd.exe prompt I get:

C:\tmp>ninja
[1/1] mv aaa bbb
FAILED: a
mv aaa bbb
CreateProcess failed: The system cannot find the file specified.
ninja: build stopped: subcommand failed.

but if I start the same ninja.exe executable from git-bash.exe then the same input and the same binary both work:

$ ninja
[1/1] mv aaa bbb

$

How exactly, that is, by which mechanism exactly, does that ninja.exe know to invoke something else and not that CreateProcess like from cmd.exe which failed?

I'm asking because I also have busybox.exe from which I can also start the posix shell from the cmd.exe, and I would like the same binary to also "know" to use that shell and not CreateProcess which fails:

C:\tmp>busybox sh
C:/tmp $ ninja
[1/1] mv aaa bbb
FAILED: a
mv aaa bbb
CreateProcess failed: The system cannot find the file specified.
ninja: build stopped: subcommand failed.
C:/tmp $

What I'm sure is that there's no only one hardcoded way in the binary as the same binary starts the process differently when invoked from git-bash.exe and when invoked from cmd.exe or busybox sh invoked from cmd.exe. Is there some environment variable to set that would allow running that specific ninja.exe "correctly" from busybox.exe started from cmd.exe?

[Biswa96]

If I go to cmd.exe prompt I get:

Because, cmd does not have mv command but cygwin, msys2, git-for-windows environments have.

m asking because I also have busybox.exe from which I can also start the posix shell

That environment should have symlinks of some programs like mv, cp etc. to busybox. See Alpine Linux or Void Linux (musl) /bin directory as example.

[janko-jj]

That's true, having mv.exe in the path would work in this case. But the second component is the parsing of the command line, and which shell is used for parsing, that matters too. How's that controlled?

[Biswa96]

which shell is used for parsing, that matters too. How's that controlled?

You have to dig into ninja source code to understand that. Or, open Process Monitor from Sysinternals to monitor new created processes.

[janko-jj]

Experimenting, I don't see that mingw-w64-x86_64-ninja uses the "right" shell parsing of the command, even when executed in git-for-windows environment. The following build.ninja file under Linux invokes both gcc and ar (because of the shell parsing of the command):

rule x
  command=gcc --version && ar --version

build a: x

But from git-bash.exe, no shell parsing happens and gcc gets everything:

$ mingw-w64-x86_64-ninja.exe
[1/1] gcc --version && ar --version
gcc.exe: error: &&: No such file or directory
gcc.exe: error: ar: No such file or directory
...

Now I conclude that the mingw-w64-x86_64-ninja.exe binary simply just doesn't use "the right shell" but always just "CreateProcess". My expectations didn't match what's there now.

This also means that the .ninja scripts which work under Linux will fail under mingw-w64-x86_64- as soon as they depend on the shell parsing. Those scripts that work, work only because they execute the .exe binaries found in the path and don't depend on shell parsing at all.