# Don't use cmd.exe when generating with Ninja on Windows

**URL:** https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215
**Category:** Usage
**Created:** [April 26, 2021, 12:44pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215 "2021-04-26T12:44:00Z")
**Posts on this page:** 18
**Page:** 1

<div class="post-metadata">

### Author: ![Andrei\_Datcu](https://discourse.cmake.org/user_avatar/discourse.cmake.org/andrei_datcu/32/1409_2.png) [@Andrei\_Datcu](https://discourse.cmake.org/u/Andrei_Datcu)
#### Post date: [April 26, 2021, 12:44pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/1 "2021-04-26T12:44:00Z")

</div>

Is there any way to use a different shell when generating a ninja file? Currently when ninja generates a run command it uses cmd.exe /c …

Looking through the cmake code, it seems that’s hard coded and cannot be changed as an option. Is there any other way to get around this limitation?

Is there a supported way to alter the ninja file as a last step of configuration?

---

<div class="post-metadata">

### Author: ![kyle.edwards](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/k/65b543/32.png) [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [April 26, 2021, 12:54pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/2 "2021-04-26T12:54:18Z")

</div>

No, I don’t believe there is a way to change it. The code that gets written to the ninja file is an implementation detail. What is your use case for changing it?

---

<div class="post-metadata">

### Author: ![Andrei\_Datcu](https://discourse.cmake.org/user_avatar/discourse.cmake.org/andrei_datcu/32/1409_2.png) [@Andrei\_Datcu](https://discourse.cmake.org/u/Andrei_Datcu)
#### Post date: [April 26, 2021, 12:56pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/3 "2021-04-26T12:56:35Z")

</div>

The most obscure of them all: I’m trying to cross compile llvm targeting arm on a windows host: for this, clang needs a bash environment to run the generated commands. I was just hoping I could avoid running the whole process through msys/mingw.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 26, 2021, 2:09pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/4 "2021-04-26T14:09:55Z")

</div>

Why does clang need a bash environment?

---

<div class="post-metadata">

### Author: ![Andrei\_Datcu](https://discourse.cmake.org/user_avatar/discourse.cmake.org/andrei_datcu/32/1409_2.png) [@Andrei\_Datcu](https://discourse.cmake.org/u/Andrei_Datcu)
#### Post date: [April 26, 2021, 2:17pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/5 "2021-04-26T14:17:27Z")

</div>

Because of this little colon here:

> <https://github.com/llvm/llvm-project/blob/llvmorg-12.0.0/llvm/cmake/modules/AddLLVM.cmake#L105>

Note that I’m building on Windows but I’m targeting Linux ARM

---

<div class="post-metadata">

### Author: ![Andrei\_Datcu](https://discourse.cmake.org/user_avatar/discourse.cmake.org/andrei_datcu/32/1409_2.png) [@Andrei\_Datcu](https://discourse.cmake.org/u/Andrei_Datcu)
#### Post date: [April 26, 2021, 2:50pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/6 "2021-04-26T14:50:43Z")

</div>

I’ve just learned about [COMSPEC - Wikipedia](https://en.wikipedia.org/wiki/COMSPEC) It would be awesome if cmake supported that!

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [April 26, 2021, 4:19pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/7 "2021-04-26T16:19:17Z")

</div>

I feel like that would be far better as a CMake script or an explicit shell script rather than trying to embed shell syntax into CMake’s language. I think that `FIXME` would also be a lot easier if it were a full shell or CMake script too.

The basic issue is that the command is assuming a bash command environment. CMake does not have any way to guarantee that such an environment is available.

---

<div class="post-metadata">

### Author: ![lindblandro](https://discourse.cmake.org/user_avatar/discourse.cmake.org/lindblandro/32/2292_2.png) [@lindblandro](https://discourse.cmake.org/u/lindblandro)
#### Post date: [March 24, 2022, 8:04pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/8 "2022-03-24T20:04:34Z")

</div>

I’ll revive this as I have another use case to add: running “cmake.exe -G Ninja” inside WSL2 fails due to cmd.exe. The exact reason is

CMD.EXE was started with the above path as the current directory.  
UNC paths are not supported. Defaulting to Windows directory.  
Fatal error[La001]: could not open file  
“C:\Windows\CMakeFiles\cmTC\_4fcd9.dir\CMakeCCompilerABI.c.o”

Powershell, for example, wouldn’t have this issue AFAIK and I would really like to change cmd.exe → powershell.exe in this case.

Searching cmd.exe references from Gitlab doesn’t produce that much hits and most of them seem to be comments about the limitations of cmd.exe. Having a way to override this, e.g. the mentioned COMSPEC, would be great.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 24, 2022, 8:39pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/9 "2022-03-24T20:39:33Z")

</div>

Use a Linux CMake inside of WSL2 when targeting Linux compilations, not a Windows one. CMake _binaries_ are platform-specific (that is, CMake is not a “cross-compiler” so to speak). This is also seen where CMake for Windows, CMake for MinGW, and CMake for Cygwin are three different things. Yes, they all run on “Windows”, but they use and target different runtimes. It’s all the same codebase, but the compilation target changes behaviors that are important to the platform at hand.

---

<div class="post-metadata">

### Author: ![lindblandro](https://discourse.cmake.org/user_avatar/discourse.cmake.org/lindblandro/32/2292_2.png) [@lindblandro](https://discourse.cmake.org/u/lindblandro)
#### Post date: [March 25, 2022, 9:18am UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/10 "2022-03-25T09:18:06Z")

</div>

I definitely would use a Linux CMake if my toolchain was running on Linux. Unfortunately, I’m stuck with IAR Windows-only toolchain for now. I probably wasn’t too clear about my setup previously but basically I’m targeting

1. ARM using IAR running on Windows (application) → `cmake.exe`
2. Linux x86-64 using GCC / Clang (unit tests and such) → `cmake`

and use WSL since switching between targets is easy and managing tools is a breeze on the Linux side of things.

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [March 25, 2022, 11:03am UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/11 "2022-03-25T11:03:28Z")

</div>

WSL doesn’t provide an environment where `cmake.exe` is expected to work though does it?

In any case, the Ninja generator uses `cmd.exe` to execute commands. I don’t think there’s a mechanism to change that.

Cc: @brad.king

---

<div class="post-metadata">

### Author: ![lindblandro](https://discourse.cmake.org/user_avatar/discourse.cmake.org/lindblandro/32/2292_2.png) [@lindblandro](https://discourse.cmake.org/u/lindblandro)
#### Post date: [March 25, 2022, 8:10pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/12 "2022-03-25T20:10:54Z")

</div>

> WSL doesn’t provide an environment where `cmake.exe` is expected to work though does it?

I know it doesn’t, that’s why I revived this topic 🙂. However, it sort of kind of almost works, but the UNC paths at least aren’t compatible.

> In any case, the Ninja generator uses `cmd.exe` to execute commands. I don’t think there’s a mechanism to change that.

Point being that maybe it would be good to have that mechanism, unless there are technical restrictions of course. I’m not well versed in CMake internals, but a quick glance produced just a few hits that explicitly reference cmd.exe:

```auto
find […] -exec grep --color -i -nH --null -e cmd.exe \{\} +
./Source/cmExecProgramCommand.cxx:149: // GetShortPathName, the cmd.exe program in windows which
./Source/cmGlobalGhsMultiGenerator.cxx:238: "cmd.exe"
./Source/cmGlobalNinjaGenerator.cxx:381: cmd = "cmd.exe /c";
./Source/cmLocalNinjaGenerator.cxx:523: cmd << "cmd.exe /C \"";
./Source/cmLocalNinjaGenerator.cxx:526: // higher precedence than "&&" in cmd.exe
./Source/cmLocalUnixMakefileGenerator3.cxx:643: makefileStream << "SHELL = cmd.exe\n"
./Source/cmSystemTools.cxx:528: // However, cmd.exe itself can only handle 8191 WCHARs and Ninja for

```

So it might be viable to add some kind of override.

---

<div class="post-metadata">

### Author: ![lindblandro](https://discourse.cmake.org/user_avatar/discourse.cmake.org/lindblandro/32/2292_2.png) [@lindblandro](https://discourse.cmake.org/u/lindblandro)
#### Post date: [March 28, 2022, 10:17am UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/13 "2022-03-28T10:17:10Z")

</div>

I tried replacing all explicit references to `cmd.exe /c` with `pwsh.exe -Command`, which did work to some extent. `pwsh.exe` is powershell 7 and is distinct from `powershell.exe` (version 5, installed by default on modern Windows machines). Powershell 7 has support for `&&` syntax in chaining commands. However, Ninja has issues with at least UNC paths that contain a literal `$`, for example: `\\wsl$\fedora\home\foo`. So all in all, the feature isn’t as trivial to implement as I’d hoped.

---

<div class="post-metadata">

### Author: ![Adam\_BZH](https://discourse.cmake.org/user_avatar/discourse.cmake.org/adam_bzh/32/5658_2.png) [@Adam\_BZH](https://discourse.cmake.org/u/Adam_BZH)
#### Post date: [July 13, 2025, 4:40am UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/14 "2025-07-13T04:40:37Z")

</div>

Sorry for bump this old thread again

Run into the same issue with different case while building micropython on windows, where it invoke sed with regex, and the regex part is causing issue with cmd.exe

Someone tried to workaround in the cmake part, but the pr did not get merged due to large changes

> <https://github.com/micropython/micropython/pull/9451>
>
> I tried to build the Zephyr port on Windows in CMD and got similar issues to #92…81.
> 
> This PR attempts to fix discovered issues:
> \* Escapes \`^\`, \`&\` in sed expressions when building on Windows.
> \* Use backslashes in \`CMAKE\_C\_COMPILER\` to avoid 
> \_"'C:' is not recognized as an internal or external
> command, operable program, or batch file."\_.
> \* Escapes \`\<\` and \`\>\` in "-DMP\_CONFIGFILE=\<mpconfigport.h\>" (\_i.e., "-DMP\_CONFIGFILE=^\<mpconfigport.h^\>"\_) - could be a problem for any port that defines \`MP\_CONFIGFILE\` in a similar way as Zephyr port does.
> 
> Fixes #9281.

* * *

I read through above discussions, and I don’t agree with Ben’s point of view, they boils down to follwoing

### “put commands in seprate script files”

Then what add\_custom\_ **command** is for?  
Most of time it’s a signle line command, what is the point to add a seprate file just for that?

### “it’s not spupose to work in your xyz environment”

Sure you could specify what guarantee to work, but that should not be the reason to telling people who are using non standard environment “you are holding it wrong (Steve Jobs TM)”  
As a build tool, it suppose to be versatile and configurable to support different environments, not to limit to a few use cases

* * *

**Three years later, do we have any workarounds?**

---

<div class="post-metadata">

### Author: ![ClausKlein](https://discourse.cmake.org/user_avatar/discourse.cmake.org/clausklein/32/352_2.png) [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [July 13, 2025, 9:49pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/15 "2025-07-13T21:49:11Z")

</div>

Dit you try to install [https://strawberryperl.com/](https://strawberryperl.com/)

It bundles all tools you need. AFAIK it is based on mingw.

---

<div class="post-metadata">

### Author: ![Adam\_BZH](https://discourse.cmake.org/user_avatar/discourse.cmake.org/adam_bzh/32/5658_2.png) [@Adam\_BZH](https://discourse.cmake.org/u/Adam_BZH)
#### Post date: [July 14, 2025, 3:14am UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/16 "2025-07-14T03:14:17Z")

</div>

I have Msys and mingw, but I’m using ESP-IDF toolchain, which come with their built of cmake  
I checked cmake source, the `cmd.exe /c` is hardcoded, which is the cause of the issue…

---

<div class="post-metadata">

### Author: ![ClausKlein](https://discourse.cmake.org/user_avatar/discourse.cmake.org/clausklein/32/352_2.png) [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [July 14, 2025, 3:36am UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/17 "2025-07-14T03:36:10Z")

</div>

Try to use the CMake for `MinGW`, it should use sh commend script AFAIK!

```auto
strawberry-perl-5.40.2.1-64bit-portable>cmake --version
cmake version 3.29.2

strawberry-perl-5.40.2.1-64bit-portable>gmake --version
GNU Make 4.4.1
Built for x86_64-w64-mingw32
Copyright (C) 1988-2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

```

---

<div class="post-metadata">

### Author: ![Adam\_BZH](https://discourse.cmake.org/user_avatar/discourse.cmake.org/adam_bzh/32/5658_2.png) [@Adam\_BZH](https://discourse.cmake.org/u/Adam_BZH)
#### Post date: [August 4, 2025, 3:00pm UTC](https://discourse.cmake.org/t/dont-use-cmd-exe-when-generating-with-ninja-on-windows/3215/18 "2025-08-04T15:00:57Z")

</div>

That did not meet my use case, the ESP IDF SDK could not work under mingw, COMSPEC should be respected instead of hard code cmd.exe

There also security concerns regarding hard code instead of allow user override [GitHub - scivision/cmake-cmd-exe: Demonstrates CMake Windows Ninja build system generation vis local cmd.exe](https://github.com/scivision/cmake-cmd-exe)
