Error: spawn cmd.exe ENOENT using WSL since 9.0.0

[simakas]

Is this a bug report?

Yes

Did you try recovering your dependencies?

Yes

Which terms did you search for in User Guide?

cmd event.js ENOENT

Environment

OS: Linux 4.4 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
Binaries:
Node: 8.11.4 - ~/.nvm/versions/node/v8.11.4/bin/node
Yarn: 1.15.2 - ~/.yarn/bin/yarn
npm: 5.6.0 - ~/.nvm/versions/node/v8.11.4/bin/npm
Browsers:
Chrome: Not Found
Firefox: 64.0
npmPackages:
react: 16.8.6
react-dom: 16.8.6
react-scripts: 3.0.1
npmGlobalPackages:
create-react-app: Not Found

Steps to Reproduce

0. react-dev-utils v 8.0.0
1. Upgrade to v.9.0.0
2. yarn install
3. yarn start
4. events.js:183
   throw er; // Unhandled 'error' event
   ^
   Error: spawn cmd.exe ENOENT

Expected Behavior

app should start using v 9.0.0

Actual Behavior

Reproducible Demo

Simply run Ubuntu or other distro on Windows WSL, upgrade to 9.0.0, same is valid for any project I tried using v9.0.0.

[mrmckeb]

Hi @simakas, this looks to be related to this issue: #7094 (comment)

Can you see if that resolves it for you, and if so, please close this off.

[cheshrkat]

@mrmckeb I've hit this issue as well; tried the path fix mentioned in that comment and it didn't resolve the problem. No change to steps or symptom/error message.

My environment info, for reference:

System:
OS: Linux 4.4 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (8) x64 Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
Binaries:
Node: 10.15.3 - ~/.nvm/versions/node/v10.15.3/bin/node
Yarn: 1.16.0 - ~/.nvm/versions/node/v10.15.3/bin/yarn
npm: 6.4.1 - ~/.nvm/versions/node/v10.15.3/bin/npm
Browsers:
Chrome: Not Found
Firefox: Not Found
npmPackages:
react: ^16.8.6 => 16.8.6
react-dom: ^16.8.6 => 16.8.6
react-scripts: 3.0.1 => 3.0.1
npmGlobalPackages:
create-react-app: Not Found

[cheshrkat]

Update - tried adding the WSL path to System32 and although it's a pretty shonky workaround it does stop the crash:

export PATH=$PATH:/mnt/c/Windows/System32

What's strange is that I'm pretty sure CRA used to work without that path set, which suggests something changed in the way it detects the environment and launches the app in browser (perhaps it was providing the path). While this workaround seems to work, I'd be a bit wary of relying on it; plus it's not particularly uncommon for WSL users to remove windows locations from their PATH.

[mrmckeb]

Thanks for the update @cheshrkat... it is a strange issue. And you're right, I ran on WSL for two years with no issue.

I'm not sure what (if anything) changed recently, but as I'm currently on a Mac (employers choice) I can't troubleshoot.

If you do find a cause on our side, feel free to raise a PR. In the meantime I'll close this off and people will hopefully find it in search if they have this issue.

[hristov296]

Having the same issue with react-scripts ver 3.0.1. Rollback to 2.1.8 does not have the issue. I tried the suggestions of adding C:\Windows\System32 to the PATH, but it didn't work for me. Here is the npm log of the error
https://pastebin.com/YbUEBSPw

[mrmckeb]

@hristov296 can you give output as above? Details of your environment, and versions?

[hristov296]

Environment Info:

System:
OS: Linux 4.4 Ubuntu 18.04.2 LTS (Bionic Beaver)
CPU: (8) x64 Intel(R) Xeon(R) CPU W3565 @ 3.20GHz
Binaries:
Node: 12.5.0 - ~/.nvm/versions/node/v12.5.0/bin/node
Yarn: Not Found
npm: 6.9.0 - ~/.nvm/versions/node/v12.5.0/bin/npm
Browsers:
Chrome: Not Found
Firefox: Not Found
npmPackages:
react: ^16.8.6 => 16.8.6
react-dom: ^16.8.6 => 16.8.6
react-scripts: ^3.0.1 => 3.0.1
npmGlobalPackages:
create-react-app: Not Found

Windows 10 Operating system -> Installed 'Ubuntu 18.04 LTS' from the store. Been using it for a year. There was no problem 2-3 months ago. Right now if I do just:

• npx create-react-app myapp
• cd myapp
• npm start
  I throws the error.
  Tested on 'react-scripts' ver 3.0.0 and 3.0.1 - there is an error.
  On version '2.1.8' it is working fine.

After some digging, I think it might be related to a newer version of webpack-dev-server

My system variables, for reference.

[bugzpodder]

Need to look into this a bit further, I didn't get any troubles when running npm start using WSL 1 and just regular command prompt on my windows 10 box. I am using a preview build that also supports WSL 2 though..

[atlefren]

Can confirm that this issue occurs on my machine, running react-scripts 3.0.1
Microsoft Windows [Version 10.0.18890.1000]

With NO windows paths set I get the error

events.js:167
      throw er; // Unhandled 'error' event
      ^
Error: spawn cmd.exe ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:231:19)
    at onErrorNT (internal/child_process.js:406:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)

If I run

export PATH=$PATH:/mnt/c/Windows/System32

Things work as expected.

An older project, using react-scripts 2.1.5 works fine without updating the path.

I agree with @cheshrkat that this is a wonky workaround, and that WSL users does not want to pollute their WSL with windows paths.

I would gladly test further improvements or provide more feedback if needed

[atlefren]

Found another workaround:

This error stems from the fact that CRA tries to open your browser:

In order to skip opening the browser, add

BROWSER=none

to your .env or .env.local file

[atlefren]

Some more digging:

Turns our, in the cases that this fails on my machine, the browser variable sent to the startBrowserProcess in

node_modules/react-dev-utils/openBrowser.js

is undefined.

I tried adding the following:

  if (browser === undefined) {
    return false;
  }

to line 90 of node_modules/react-dev-utils/openBrowser.js and things again worked as expected.

I'm not sure if you want a PR with this, or if this info is enough?

Also: Not sure if this issue persists on master, where the opn library has been replaced with open?

[mrmckeb]

Hey @atlefren, a PR would be great if you can - if you're not able, or want to pair, let me know!

[atlefren]

I'll give it a try tomorrow! Just wanted to know if I should base this off master, or the relevant branch for the 3.0.1 version of react-scripts? Also: how do I run CRA from a local copy? (aka: where do I find relevant docs for development)

[mrmckeb]

Correct - just fork and go.

The easiest ways to test locally are with (assuming Yarn, but npm has the same things):

• yarn link in the react-scripts folder, then run yarn link react-scripts in a project that has been set up with CRA. You'll then be using your local react-scripts until you unlink.
• yarn add file:/.../create-react-app/packages/react-scripts to your project.

[bugzpodder]

If you are only touching one file, I think the easiest way is to just goto node_modules/react_scripts and modify the file directly.

[drwatsoncode]

This problem is not caused by the browser argument in openBrowser being undefined. That variable is supposed to be undefined in most cases (unless the user has set the BROWSER environment variable).

One workaround is to set BROWSER to "none". This will prevent any browser from being launched.

BROWSER=none  yarn start
#  or
BROWSER=none  npm start
#  or
export BROWSER=none
yarn start
...

The real problem is inside the "opn" package, which has been renamed to open. The opn function attempts to launch a browser on Windows (with or without WSL) by running cmd.exe ... start. The problem is that cmd.exe is not on the WSL path by default. So a workaround (that has been suggested above) is to add to the PATH:

PATH="$PATH:/mnt/c/Windows/System32"   yarn start   # (or npm start)

or

export PATH="$PATH:/mnt/c/Windows/System32"
yarn start    # (or npm start)

The former command will not alter your current shell while the latter will, so choose the one that suits your needs best.

[curreta]

FWIW I had previously edited my windows registry to exclude windows paths for an unrelated issue as per this comment. Changing it back to 7 "fixed" this issue for me.

[atlefren]

This.

I am rather certain that assuming that everybody has their windows paths present in WSL is to beg for trouble.

Whether this is a CRA-issue, an open issue or a WSL issue is more of an academic question. The problem is that many WSL users will have an issue when updating to CRA 3.0, with no decent error messages.

As we've found in sindresorhus/open#144 this issue is possible to solve in the open library.

FWIW I had previously edited my windows registry to exclude windows paths for an unrelated issue as per this comment. Changing it back to 7 "fixed" this issue for me.

[HamburgerTwo]

I have resolve this problem by granted access to windows system permissions for wsl, may be the problem caused by some library run "cmd.exe" commend but wsl doesn't have the permissions to excute the windows's program

[AaronFriel]

Edit: I've traced it down here: sindresorhus/open#157

I don't know how or why cmd.exe is being invoked, but I can reproduce this on my machine when building and run an image from Docker on Windows. Setting BROWSER: none in docker-compose.yml fixes it.

The weird thing is, it's being built on the image node:10, for the linux/amd64 platform, on Linux with kernel 4.19. I've traced it down to:

Package open uses is-wsl, which detects the Docker container as being WSL-capable, which then tries to invoke cmd.exe.

[takasoft]

This is probably the easiest fix. Just modify the start script in package.json

"scripts": {
    "start": "BROWSER=none react-scripts start"
  }

[devfarhan86]

Append this to your Path it worked fine for me.

C:\Windows\System32

[grenade]

there's not really a simple way to fix this for wsl that isn't ugly for other platforms. a simple workaround for wsl users is to just temporarily append the required path by modifying package.json so that the yarn start command is prefixed with a temporary PATH var that contains the folder containing cmd.exe. on most ubuntu wsl setups this looks like this:

  "scripts": {
    "start": "PATH=$PATH:/mnt/c/Windows/System32 react-scripts start",

[mostaffa]

Just Add the following to your System Environment (PATH):
%SystemRoot%\system32
it worked with me

[ireznik]

Found another workaround:

This error stems from the fact that CRA tries to open your browser:

In order to skip opening the browser, add

BROWSER=none

to your .env or .env.local file

Thanks for saving me time <3

[jtwing62173]

Worth mentioning that for WSL2 and Windows 10 later versions, the path to add to $PATH is different. I'm on Windows 10 Version 10.0.18362 Build 18362, running Kali Linux as my dev environment via WSL2, and this worked for me:

# shim to enable openBrowser from react-dev-tools to find and launch browser using powershell.exe export PATH=$PATH:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/

adding 'if (!browser) return false;' to openBrowser.js from ./node_modules/react-dev-tools also works, but if you do ANY kind of install operation... it gets blown away.

The .env fix also works, but now you're managing the browser open and refresh yourself, because the linkage between the webpack dev server and the browser gets a bit borked when you turn BROWSER=none.

What I would REALLY prefer... is for 'them' to fix it. I'd submit a pull request myself but I can't be arsed to fiddle with all of the process required to test every permutation on every system combination...

Hope this helps!

[JaffParker]

I've run into the same issue, but I have a bit of a wonky setup. I have a gaming PC which I decided to double as my dev server since WSL is so great now. I installed it, set it up, CRA starts without issues. However, when I try to do the same thing over a remote SSH connection, CRA thinks I'm still on the actual machine and tries to open the window, but now the env variables are different. I added the BROWSER="none" variable and that fixed it, but it feels like detection of remote environments should be improved

[ledtest]

Update - tried adding the WSL path to System32 and although it's a pretty shonky workaround it does stop the crash:

export PATH=$PATH:/mnt/c/Windows/System32

What's strange is that I'm pretty sure CRA used to work without that path set, which suggests something changed in the way it detects the environment and launches the app in browser (perhaps it was providing the path). While this workaround seems to work, I'd be a bit wary of relying on it; plus it's not particularly uncommon for WSL users to remove windows locations from their PATH.

Also worked perfect for me.

[WoxWik]

If you don't want to modify your package.json, or add windows paths:

export BROWSER ="none"

or in Fish:

set -x -U BROWSER none