I am having an issue with spawnSync is giving me ENOENT with simple "npm install". Can someone please help me?
======= NODE SCRIPT ==========
var child = require('child_process').spawnSync('npm', ['install']);
console.log(child.error);
===== OUTPUT ==========
[Error: spawnSync npm ENOENT]
code: 'ENOENT',
errno: 'ENOENT',
syscall: 'spawnSync npm',
path: 'npm',
spawnargs: [ 'install' ]
only on windows but not on OS X.
This happens on
windows 7 x64
node version: 4.4.3
npm version: 2.15.1
I figured out the issue. On Windows, some commands need to be suffixed with .cmd in order to work. In this example, this updated command works for me:
require('child_process').spawnSync('npm.cmd', ['install']);
Or you can use cross-spawn to make it work cross-platform
I solved this by specifying the shell to be the v1 32-bit Powershell executable.
I don't know if there is a more reliable method of getting the Powershell executable path, but this is what I did:
const { spawnSync } = require('child_process')
const path = require('path')
const shell = process.platform === 'win32'
? 'C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe'
: undefined
const r0 = spawnSync('pnpm', ['run', 'build'], {
cwd: path.join(__dirname, '..', 'projects', 'project-name'),
env: process.env,
stdio: 'inherit',
shell
})
if (r0.error) {
console.log(r0.error)
process.exit(1)
}
Related
I'm trying to execute a cli command using child_process.spawnSync to unzip a file, but when I run the code it says ENOENT even though the command works fine.
const result = spawnSync(`unzip ${path}`, [
passwordArg, // ''
outputArg, // ''
]);
// console.log(result)
error: Error: spawnSync unzip /<...>/unzipFiles/test/zipp.zip ENOENT
...
errno: -2,
code: 'ENOENT',
syscall: 'spawnSync unzip /<...>/unzipFiles/test/zipp.zip',
path: 'unzip /<...>/unzipFiles/test/zipp.zip',
spawnargs: ['', '']
If I copy and paste and execute the exact value for path, i.e. unzip /<...>/unzipFiles/test/zipp.zip, it runs as expected.
Any help would be much appreciated.
I have working on an electron desktop application, the app is quite simple its about building a file browser for Linux. From Nodejs apis I use child_process, fs, path, os, and so on.
I am using electron-builder to package and build the application.
When I build for linux with target like "zip", "deb", "rpm", the application works as expected.
But when I compile for snap. I can't run commands like:
const util = require('util');
const exec = util.promisify(require('child_process').exec);
await exec('which code');
.....
await openExternalApp('code -n', `"${file.path}"`)
.....
async function openExternalApp(cmd, path) {
const util = require('util');
const exec = util.promisify(require('child_process').exec);
await exec(`${cmd} ${path}`);
}
.....
I got an error:
Error: Command failed: which code
at ChildProcess.exithandler (node:child_process:406:12)
at ChildProcess.emit (node:events:390:28)
at maybeClose (node:internal/child_process:1064:16)
at Socket.<anonymous> (node:internal/child_process:450:11)
at Socket.emit (node:events:390:28)
at Pipe.<anonymous> (node:net:687:12) {
killed: false,
code: 1,
signal: null,
cmd: 'which code',
stdout: '',
stderr: ''
}
Error: Command failed: which code
Also in my program when i have to read directories of the file system related with hard drive or another location simply i can't.
I've started to study a little bit the docs in snap store and I realized that you have to configure the slot, layout and slugs to access the whole file system, and perhaps to run bash or shell command like the one above.
After several configuration i continue with the same issues. Here is my configuration for snap in pakage.json
"snap": {
"plugs": [
"desktop",
"desktop-legacy",
"home",
"x11",
"unity7",
"browser-support",
"network",
"gsettings",
"opengl",
"block-devices",
"classic-support",
"hardware-observe",
"home",
"system-backup",
"system-observe",
"process-control",
"hostname-control",
"removable-media",
{
"system-files": {
"read": [
"/etc",
"/usr",
"/home",
"/media",
"/mnt",
"/var",
"/temp",
"/opt",
"/sys",
"/dev",
"/bin",
"/snap"
],
"write": [
"/home",
"/mnt"
]
}
}
],
"desktop": {
"Encoding": "UTF-8",
"Icon": "${SNAP}/icon.png"
}
}
snap image config in pakage.json
I have installed a npm packages globally in my Kubuntu 19.04
$ npm install -g cordova
/home/username/.npm-global/bin/cordova -> /home/username/.npm-global/lib/node_modules/cordova/bin/cordova
+ cordova#9.0.0
updated 1 package in 7.299s
I can access it from shell
$ cordova -v
9.0.0 (cordova-lib#9.0.1)
But I can't access it from a simple node script with spawn:
const { spawn } = require( 'child_process' );
const cmd = spawn( 'cordova', [ '-v' ] );
cmd.stdout.on( 'data', data => {
console.log( `stdout: ${data}` );
} );
Running it results in the following:
$ node test1.js
events.js:298
throw er; // Unhandled 'error' event
^
Error: spawn cordova ENOENT
at Process.ChildProcess._handle.onexit (internal/child_process.js:267:19)
at onErrorNT (internal/child_process.js:467:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
Emitted 'error' event on ChildProcess instance at:
at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
at onErrorNT (internal/child_process.js:467:16)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
errno: -2,
code: 'ENOENT',
syscall: 'spawn cordova',
path: 'cordova',
spawnargs: [ '-v' ]
}
But when using absolute path:
const { spawn } = require( 'child_process' );
const cmd = spawn( '/home/username/.npm-global/bin/cordova', [ '-v' ] );
cmd.stdout.on( 'data', data => {
console.log( `stdout: ${data}` );
} );
I get the expected result:
$ node test1.js
stdout: 9.0.0 (cordova-lib#9.0.1)
My script above is just a testcase, since I have problem to add/run cordova specific stuff in vue-cli-plugin-cordova and quasar. I tracked it down, that the global path is the problem.
Update
I think I found the problem, but not sure how to solve it. When setting /bin/bash as shell, it works:
cmd = spawn('cordova', ['-v'], {
shell: '/bin/bash'
});
Not sure, why this is needed and why the packages vue-cli-plugin-cordova and quasar don't do it.
Ok, after hours of research and tryouts, I have uninstalled node, installed nvm and latest node, set
nvm use --delete-prefix v13.7.0 --silent >> /dev/null
and added this to ~/.bashrc
and now everything works
how I solve my error, I changed the environment variable PATH: to C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;{plus program paths}
which is
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Program Files\nodejs
in my PATH
I want to execute the Electron application by child_process.spawn:
import ChildProcess, {ChildProcess as ChildProcess__type} from 'child_process';
const childProcess: ChildProcess__type = ChildProcess.spawn(
'electron',
['ProjectInitializer__ElectronMain.js'],
{ cwd: __dirname } // current project root
);
I got Error: spawn electron ENOENT error. Electron has been installed locally, AFAIK is the good practice. Also, electron ProjectInitializer__ElectronMain.js works, it to execute this console command from my project directory.
Following frequently up-voted ENOENT error debugging guidance, I got the cause: there is no directory among process.env.PATH, which includes electron.
I know about PATH variable not much, so I can not answer what must be in this variable and what is not. But what I want to ask is: how to execute locally installed (in node_modules) Node.js applications (like electron)?
By the way, execa which is known as improved child_process runs electron without errors (update: version 2.x.x already do not runs):
import executeExternalCommand, { ExecaReturnValue } from 'execa';
try {
await executeExternalCommand(
'electron',
['ProjectInitializer__ElectronMain.js'],
{ cwd: __dirname }
);
} catch (error) {
console.error(error);
}
Somehow, thanks to { cwd: __dirname }, the execa v 1.x.x knows, where should to find the electron. Unfortunately, execa has too small community and small documentations, so stopped to use it.
Additional information
How I run this Node.js script which has the spawn parameter
By command my-library init which I created.
In package.json:
"bin": {
"my-library": "bin/my-library"
}
In bin/my-library (no filename extension):
#!/usr/bin/env node
require('../CLI').interpretConsoleCommandAndExecute(process.argv);
In CLI.js I parse the console command, and if it is the my-library init, I'll try to execute
const childProcess: ChildProcess__type = ChildProcess.spawn(
'electron',
[ 'ProjectInitializer__ElectronMain.js' ],
{ cwd: __dirname }
);
console.log(process.env) output
Below output is for PhpStorm build-in console, however in other consoles, e. g. in cmder, output is different.
{ FPS_BROWSER_APP_PROFILE_STRING: 'Internet Explorer',
CommonProgramFiles: 'C:\\Program Files\\Common Files',
PROMPT: '$P$G',
SESSIONNAME: 'Console',
COMPUTERNAME: 'MSI',
OneDriveConsumer: 'D:\\OneDrive',
__INTELLIJ_COMMAND_HISTFILE__:
'C:\\Users\\i\\.PhpStorm2019.1\\config\\terminal\\history\\history-34',
SystemDrive: 'C:',
NUMBER_OF_PROCESSORS: '12',
LOGONSERVER: '\\\\MSI',
TEMP: 'C:\\Users\\i\\AppData\\Local\\Temp',
TMP: 'C:\\Users\\i\\AppData\\Local\\Temp',
HOMEPATH: '\\Users\\i',
PATHEXT: '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JSE;.WSF;.WSH;.MSC',
USERNAME: 'i',
ProgramFiles: 'C:\\Program Files',
USERDOMAIN_ROAMINGPROFILE: 'MSI',
LOCALAPPDATA: 'C:\\Users\\i\\AppData\\Local',
TERMINAL_EMULATOR: 'JetBrains-JediTerm',
PROCESSOR_IDENTIFIER: 'Intel64 Family 6 Model 158 Stepping 10, GenuineIntel',
DriverData: 'C:\\Windows\\System32\\Drivers\\DriverData',
APPDATA: 'C:\\Users\\i\\AppData\\Roaming',
ALLUSERSPROFILE: 'C:\\ProgramData',
USERDOMAIN: 'MSI',
OS: 'Windows_NT',
PROCESSOR_LEVEL: '6',
ProgramData: 'C:\\ProgramData',
ComSpec: 'C:\\Windows\\system32\\cmd.exe',
PROCESSOR_ARCHITECTURE: 'AMD64',
FPS_BROWSER_USER_PROFILE_STRING: 'Default',
SystemRoot: 'C:\\Windows',
PROCESSOR_REVISION: '9e0a',
OneDrive: 'D:\\OneDrive',
PSModulePath:
'C:\\Program Files\\WindowsPowerShell\\Modules;C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules',
PATH:
'D:\\PhpStorm\\InHouseDevelopment\\my-library\\node_modules\\.bin;C:\\ProgramData\\DockerDesktop\\version-bin;C:\\Program Files\\Docker\\Docker\\Resources\\bin;C:\\Program Files (x86)\\Intel\\Intel(R) Management Engine Components\\iCLS\\;C:\\Program Files
\\Intel\\Intel(R) Management Engine Components\\iCLS\\;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Windows\\System32\\OpenSSH\\;C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common;C:\\Pro
gram Files\\Intel\\WiFi\\bin\\;C:\\Program Files\\Common Files\\Intel\\WirelessCommon\\;C:\\Program Files (x86)\\Intel\\Intel(R) Management Engine Components\\DAL;C:\\Program Files\\Intel\\Intel(R) Management Engine Components\\DAL;C:\\Program Files (x86)\\Intel\\I
ntel(R) Management Engine Components\\IPT;C:\\Program Files\\Intel\\Intel(R) Management Engine Components\\IPT;C:\\Program Files (x86)\\Common Files\\Acronis\\VirtualFile\\;C:\\Program Files (x86)\\Common Files\\Acronis\\VirtualFile64\\;C:\\Program Files (x86)\\Com
mon Files\\Acronis\\FileProtector\\;C:\\Program Files (x86)\\Common Files\\Acronis\\FileProtector64\\;C:\\Program Files (x86)\\Common Files\\Acronis\\SnapAPI\\;C:\\Program Files\\nodejs\\;C:\\Program Files\\Git\\cmd;C:\\Program Files (x86)\\Yarn\\bin\\;C:\\Users\\t
okug\\AppData\\Local\\Microsoft\\WindowsApps;C:\\Users\\i\\AppData\\Roaming\\npm;C:\\Users\\i\\AppData\\Local\\Yarn\\bin;C:\\texlive\\2019\\bin\\win32',
'ProgramFiles(x86)': 'C:\\Program Files (x86)',
USERPROFILE: 'C:\\Users\\i',
windir: 'C:\\Windows',
ProgramW6432: 'C:\\Program Files',
configsetroot: 'C:\\Windows\\ConfigSetRoot',
'CommonProgramFiles(x86)': 'C:\\Program Files (x86)\\Common Files',
PUBLIC: 'C:\\Users\\Public',
HOMEDRIVE: 'C:',
CommonProgramW6432: 'C:\\Program Files\\Common Files' }
Trying to execute ChildProcess.spawn('env')
In Php Strorm console, it causes familiar Error: spawn env ENOENT.
As discussed in the chat, the error you are getting is usually caused by the fact that the executable you are trying to run is not available
Now there are multiple reasons the executable may not be available
The executable is not there at all anywhere on the system
The executable is there but not in the folders defined by system's PATH variable
The executable is there in the current directory but the directory context in which the process is being run is different
To fix #1 and #2 you just install the executable globally in system PATH
For fixing #3 you can do two things. Add the path for the current directory ({ cwd: __dirname}) and also a relative path to executable
const childProcess: ChildProcess__type = ChildProcess.spawn(
Path.resolve(__dirname, 'node_modules/.bin/electron'),
[ Path.resolve(__dirname, 'ProjectInitializer__ElectronMain.js') ],
{ cwd: __dirname}
);
or
const childProcess: ChildProcess__type = ChildProcess.spawn(
'./node_modules/.bin/electron'),
[ Path.resolve(__dirname, 'ProjectInitializer__ElectronMain.js') ],
{ cwd: __dirname}
);
or
const childProcess: ChildProcess__type = ChildProcess.spawn(
'node_modules/.bin/electron',
[ './ProjectInitializer__ElectronMain.js' ],
{ cwd: __dirname}
);
In case you decide to override the PATH environment variable you can do it passing the env parameters with more values
const childProcess: ChildProcess__type = ChildProcess.spawn(
'node_modules/.bin/electron',
[ './ProjectInitializer__ElectronMain.js' ],
{ cwd: __dirname, env: {....}}
);
You can use the existing environment variables from process.env and then update the same, and pass it to env parameter
it’s likely that you need to specify the full path to the electron command, since it isn’t on your path.
If you are running your script from your project root, electron is probably at in ./node_modules/.bin/electron, if they packaged up the app to be run that way.
I would guess that your alternative library checks node_modules by default.
The alternative would be to ensure electron is in your path, but that requires updating your system configuration, which it would be weird for a library to do.
Edit: example of call with path:
const childProcess: ChildProcess__type = ChildProcess.spawn(
'node_modules/.bin/electron',
[ 'ProjectInitializer__ElectronMain.js' ],
{ cwd: __dirname }
);
I'd also add some dumb logging on the process, so you know why the process failed:
function log(data) {
console.log("" + data)
}
child_process.stdout.on('data', log)
child_process.stderr.on('data', log)
child_process.on('close', log)
I try to create a windows installer for my elctron application but when I run the file I have this error:
spawn mono ENOENT
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! thermowell-design#1.2.0 installer-win: `npm run pack-win && node installers/windows/createinstaller.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the thermowell-design#1.2.0 installer-win script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
This is the createinstaller.js file:
const createWindowsInstaller = require('electron-winstaller').createWindowsInstaller
const path = require('path')
getInstallerConfig()
.then(createWindowsInstaller)
.catch((error) => {
console.error(error.message || error)
process.exit(1)
})
function getInstallerConfig () {
console.log('creating windows installer')
const rootPath = path.join('./')
const outPath = path.join(rootPath, 'release-builds')
return Promise.resolve({
appDirectory: path.join(outPath, 'Thermowell-Design-win32-x64/'),
authors: 'Pippo',
noMsi: true,
outputDirectory: path.join(outPath, 'windows-installer'),
exe: 'thermowell-design.exe',
setupExe: 'thermowell-design-app.exe',
setupIcon: path.join(rootPath, 'assets', 'images', 'icons', 'logo.ico')
})
}
There are the dependencie version:
electron: 5.0.0-beta.2,
electron-packager: 13.0.1,
electron-winstaller: 2.7.0
end the nodejs version is 10.15.1
It's too late to answer but leaving it for somebody if they need it in future. I got the same problem and here are my fixes:
depending upon my project structure I changed rootPath = path.join(__dirname,'../..')
install mono from https://www.mono-project.com/download/stable/#download-lin-ubuntu
install wine from https://tecadmin.net/install-wine-on-ubuntu/
The two installations are for non-windows platform if your building your installer for windows platform
Those were my fixes but here's another link that might be helpful for you.