spawn /path/to/file/code.cmd ENOENT, The system cannot find the path specified.

[Eskibear]

I'm using [email protected] in an Electron app (using [email protected]). And my code is as below, and here I use <username> to represent username of current user.

const command = "C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd";
const args = ["--install-extension", "vscjava.vscode-java-pack"];
await execa(command, args);

And it turns out some users report below error, even though I don't know how to reproduce it. e.g. https://github.com/microsoft/vscode-java-pack/issues/292

Error: Command failed with ENOENT: C:\Users\<username>\AppData\Local\Programs\Microsoft VS 
Code\bin\code.cmd --install-extension vscjava.vscode-java-pack
spawn C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd ENOENT
The system cannot find the path specified.

What I know is, code.cmd is there in the correct location, C:\Windows\System32 is included in their PATH, and cmd.exe exists. Do you have any clue about it?

[ehmicky]

Hi @Eskibear,

What happens if you use execFile() instead of execa() the following commands show?

const { execFile } = require('child_process')
const { promisify } = require('util')
// Try `pExecFile()` instead of `execa()`
const pExecFile = promisify(execFile)

[Eskibear]

Thank you for the information. But as I mentioned, I cannot reproduce it myself. The only way I can think of is, to create a private build of my product, and ask those who have this issue to test.

I'm not that exprienced in JS, and if you think execFile should work, I'll give it a try.

[ehmicky]

I actually think execFile() will not work, i.e. throw an error. This would mean the problem is not specific to Execa but that the command being executed is invalid.

ENOENT should happen when the path executed is invalid, which probably means C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd does not exist. Without any reproduction code, this is my best guess at the moment.

Another thing to try would be to add the shell: true option, as this might also be an issue with executing *.cmd files on cmd.exe, or with the PATHEXT environment variable.

[Eskibear]

Great appreciation. I'll create one more private build, still using execa, adding shell:true and quoting the path (suggested by child_process doc).

• BTW, as execa declare to have better Windows support because of using cross-spawn, I don't know if it's by design or.. a bug, on my machine, execa("C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd", args, {shell: true}) fails because of the spaces in file path.

I'll let you know if it works for them. (But don't expect a quick feedback, it depends on others whether to test my private build)

[bengunnewijkGeonovum]

I had this same issue due to an "invalid" cwd.

I was calling execa somewhat like this: program: 'ant' parameters: [ '-version' ] options: { cwd: '"/usr/share/ant/bin"', env: {}, shell: false }

I was encapsulating cwd in quotes to allow spaces in directory names but this caused an ENOENT error: spawn ant ENOENT at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19) at onErrorNT (node:internal/child_process:476:16) at processTicksAndRejections (node:internal/process/task_queues:82:21)

On Windows the quoted cwd worked fine but on linux it didn't. Specifically, on Ubuntu where process.platform === "linux" Execa version: 7.2.0

With this error it is difficult to distinguish whether it couldn't find the program, one of the arguments or the cwd. Although I suppose that's due to commandline design and not Execa.

[ehmicky]

Hi @bengunnewijkGeonovum,

The value of the cwd option never needs to be quoted, because it is not interpreted by a shell. Spaces are always allowed in both Unix and Windows.

@Eskibear I am closing this issue as stale, please let me know if I should re-open.