Call to shell and get response

electron
#1 
var child_process = require('child_process');
var output = child_process.execSync('echo %username% is stupid :( ');
alert(output);

Simply trying to execute echo %username% is stupid :( in Windows’s CMD, and get output of it, which would be admin is stupid :(, but, instead I get hugged with message:
Uncaught Error: EPERM: operation not permitted, write from fs.js:663.
sigh, I could guess what E_Permission is but I don’t know how to grant it, nor how assigning variable involves I/O management (fs.js).

This Sir have found an answer? But then after some attempts he gave up handling it with try and catch. I’d just like to save the answer in variable. Possible :stuck_out_tongue:?

I’ve done some further research on that, but the solutions have been either too old (and repositories redirected me to “child-process”) or they weren’t solving my issue as they forced me to write it in a file, the list goes on.

#2

It is possible to start a process on Windows without sending it first through cmd.exe, which is what would process both echo and the %username% variable expansion. It is quite possible that child_process does not use cmd.exe to execute processes on Windows. Given this, have you tried:

var child_process = require('child_process');
var output = child_process.execSync('cmd.exe /c "echo %username% is stupid :("');
alert(output);
#3

I haven’t tried this, but unfortunately this solution doesn’t seem to work for me, same error occurs :frowning:

#4

Then you’re going to need to include more information. Posting the entire stack trace (rather than just the first line) might be helpful. My bug-report package uses child_process for running processes on Windows and nobody has reported this issue with it. (Granted, it isn’t a very popular package … but still.)

#5

trackattempt.png1366×663 69.6 KB

console.trace(); returns nothing vital. Also, I’ve never sought for Stack Trace when coding websites in JavaScript. New territory here.

My attempt at tracing it, failed to stop the script execution at error occurrence:

trackattempt.png1366×663 69.6 KB

This is tutorial I based myself on, mind helping me extracting these stack traces?

#6

When posting screenshots, just leave them inline in the text. I don’t think the image upload system is supposed to work the way you’re trying to use it.

#7

Updated :wink:

#8

console.trace outputs a stack trace for wherever the code is when the trace function is called. I meant the full stack trace of the EPERM error. That will pinpoint exactly what is causing the issue.

#9 
Error: EPERM: operation not permitted, write
    at Error (native)
    at Object.fs.writeSync (fs.js:663:20)
    at SyncWriteStream.write (fs.js:1931:6)
    at Object.execSync (child_process.js:485:20)
    at file:///C:/Users/BBB/Desktop/AAA_app/iron.js:3:29

It took only 20 minutes to figure out that you need try() and throw().

#10

It looks like it is failing here:

About which the documentation says:

stderr by default will be output to the parent process’ stderr unless stdio is specified

So perhaps specifying some other options would make things work better?

#11

There’s something about it here, I also got the entire idea from there. How the heck would I specify this? What is this black magicks!?

And I get stuck here already. Isn’t the stdio[0] already defined?

  • input String|Buffer The value which will be passed as stdin to the spawned process
    – supplying this value will override stdio[0]
  • stdio Array Child’s stdio configuration. (Default: ‘pipe’)
    – stderr by default will be output to the parent process’ stderr unless stdio is specified

But stdio[0] already default apprently… boy I don’t like Node.JS, will be a rogue way to learn.

How can I assign a buffer to stdio[0] and print output there, does Node.JS even operate with buffers from which I could read?

I will try:
var output = child_process.execSync('cmd.exe /c "echo %username% is stupid :("', null, true);
Be right back.
Edit: Nope Node.JS still hates me.

#12

Sorry, I don’t have a Windows machine to test on. I don’t have any more suggestions other than see if there are examples somewhere on how to buffer the output yourself.

#13

Yes indeed. Linux doesn’t have any simple problems with ls command, however ll is denied :frowning:, even though ll is a working command too. Could you please tell me what are precise commands that I’m allowed to use? I thought that execSync() allowed interaction with terminal, but this command (and maybe others) are apparently disregarded. Is there a list of “blocked” commands or they’re just not supported?

Oh well, I was developping for Linux anyways.

#14

There is no list of blocked commands but the PATH (and maybe other environment variables) used by child_process might not be the same as what your user login gets. So you may need to use the full path to the executable.

#15

So you may need to use the full path to the executable.
?, nope, dragging the folder in the area, typing the full entire paths in console. The error is still:

Uncaught Error: Command failed: ll
/bin/sh: 1: ll: not found

I could survive it, however, I’m feeling that I might require full power of Linux’s shell later, and if ll is blocked, it might be that future functions are blocked too. Oh, and stack:

Error: Command failed: ll
/bin/sh: 1: ll: not found

    at checkExecSyncError (child_process.js:453:13)
    at Object.execSync (child_process.js:493:13)
    at file:///home/ubuntu/Desktop/AAA_app/index.html:4:30

Not that it’d help, we know the issue, we don’t know the solution yet :frowning:

#16

This is nothing to do with the Electron (or even node really).

> ll
total 0

> sudo ll
sudo: ll: command not found

Also try to look for a node module that does whatever it is you’re trying to shell out for; e.g. using fs.readdir instead of using child_process and ls.

#17

ls is an executable in most flavors of Linux. ll is an alias that is set up commonly in one’s shell profile. Your shell profile is probably not getting executed by execSync. So ll is not blocked … it just doesn’t exist in the same way as ls does:

$ which ls
/bin/ls
$ which ll
ll: aliased to ls -lhF

So if you check to see what your version of ll is aliased to, if you execute ls -lhF or whatever it is aliased to, things should work fine.

1 Like
#18

Not really a solution to this problem, but if you’re just trying to get the username environment variable you can just do process.env.username.

#19

I’m not sure if this was ever resolved from reading the replies. I had the same issue in an Atom package I parent.

Another contributor figured it out. Thank you @faleij !! I’ll save you from digging through that thread:

Fix for this (Tested on Windows only):
return ChildProcess.execSync(cmd, {stdio: 'pipe' }).toString();

(they added {stdio: 'pipe'})

2 Likes
#20

Thanks @Bee!

On Mac I was able to do:

return ChildProcess.execSync( command ).toString();

Without the {stdio: 'pipe'} and it worked just great.

Thanks!