It's impossible to run Electron or Electron apps from within Atom

[DamnedScholar]

This appears to have been floating around everywhere except here. @Fred-Barclay did some investigation and made an extensive post on the forums.

From Linux:

$ atom AUTHORS
$ electron: bad option: --app=/usr/lib/atom
electron: bad option: --executed-from=/home/fred/Git/Termination
electron: bad option: --pid=3824

From macOS:

LSOpenURLsWithRole() failed for the application /Applications/Atom.app with error -10810.
projects $ atom README.md
LSOpenURLsWithRole() failed for the application /Applications/Atom.app with error -10810.

After doing some digging it appears that electron is being set to run as node (and then this affects Atom - I'm not sure exactly how yet) so that when atom is passed into the terminal, node is called instead. You can see this when you compare the output of commands run inside termination:

$ atom --version 
v6.5.0
$ electron --version
v6.5.0
$ node --version
v7.3.0

to commands run in a dedicated system terminal

$ atom --version
Atom    : 1.12.7
Electron: 1.4.13
Chrome  : 53.0.2785.143
Node    : 6.5.0
$ electron --version
v1.4.13
$ node --version
v7.3.0

On Windows 10, I am not able to execute or see any error messages regarding Atom or the other program I've been testing this with (GitKraken); atom --version just bumps me back to the prompt when used from within Atom.

On platformio-ide-terminal, @jbrodriguez posted on November 11 that it used to work and stopped working following an update. In the same thread, @BenSjoberg found a solution for Unix machines, and running the command with sudo may work (see that thread).

[50Wliu]

Well, we do have this thing here.

Your examples also only reference Atom and Electron. Are other Electron apps affected as well?

The macOS error might provide some insight into why #3093 occurs.

[DamnedScholar]

@Fred-Barclay reported in the forum post that he worked around it by unsetting the variable tvia termination, but that this didn't work when added to the package code as an initial command (the package froze).

Further supporting this is the fact that if unset ELECTRON_RUN_AS_NODE is run from inside termination, atom and other commands behave ordinarily.

I'd like to remove this behavior, but I'm not sure exactly how to go about that. I've tried setting up the termination initialisation code to pass unset ELECTRON_RUN_AS_NODE through the system shell whenever a terminal is generated, but that seemed to just freeze termination.

I've also tried modifying process.coffee1 to contain env.ELECTRON_RUN_AS_NODE = 0 but this has had absolutely no effect.

I have been testing with GitKraken, which uses Electron. The same command that opens GitKraken or Atom in my external terminal just bumps me back to the prompt when used from a terminal embedded in Atom. I just tried it in Monterey and the behavior is the same. I cannot currently test whether GitKraken or Monterey behave the same on the other platforms.

[RomanADavis]

So, we should kick this up to the electron repo?

[DamnedScholar]

The environment variable is set by Atom's code, so no, this is not an Electron issue (unless I misunderstand why the environment variable was implemented in the first place and the only way to change Atom's behavior is to change Electron's).

[RomanADavis]

Then why does GitKraken have the same problem?

[DamnedScholar]

It doesn't. GitKraken is an Electron application that I happen to have installed and was testing with to see if trying to open it behaves the same way as trying to open Atom or Electron.

[RomanADavis]

Yeah, but I thought changing that didn't fix it. If it did, we'd just change the 1 to a higher number and push, right? Or to a zero? Is this some weird C-like thing where 1 is being used in place of true?

[DamnedScholar]

For the test to have termination unset the variable, it worked when the unset command was run from within the terminal but trying to override it in the JavaScript was ineffective.

1 and 0 for true and false is far older than C. George Boole introduced what would later be called Boolean algebra in 1847.

[RomanADavis]

Wait, so there is a way to open Atom from inside an atom terminal, you just have to run some other command? How do I do that?

[RomanADavis]

So again, why don't we just fork it, change it to 0, then push? Does this break the program somehow?

[Fred-Barclay]

@RomanADavis
That command would be unset ELECTRON_RUN_AS_NODE.

Changing the Atom code to options.env.ELECTRON_RUN_AS_NODE = 1 might break something... I wouldn't be the best person to know how or what its effect would be.

[RomanADavis]

Trying to figure out how to do that on my Windows machine. (I really just need to move to Linux.)

[Fred-Barclay]

"(I really just need to move to Linux.)"
Yup! 😉

Is there not a Windows equivalent to unset? Maybe undefine or whatnot?

[50Wliu]

Try set ELECTRON_RUN_AS_NODE=

[lee-dohm]

I was just able to run a toy Electron app I have built using Node's child_process.exec from Atom:

> let foo = require('child_process').exec
undefined
> foo('script/start', {'cwd': '/Users/Lee/Source/hero-database'})
ChildProcess {domain: null, _events: EventHandlers, _eventsCount: 2, _maxListeners: undefined, _closesNeeded: 3…}

The app window showed up and everything. So, at the very least, the title is incorrect. It is possible that there are certain ways that make running an Electron application from within Atom harder than others, but it is not impossible. I'm not convinced there is a bug here.

[Hum4n01d]

Having the same issue

[gmanriqueUy]

Same here as well.

[lee-dohm]

There doesn't seem to be a bug here. Yes, you can't run an Electron app from within Atom using the technique described. On the other hand, child_process seems to work just fine for launching Electron applications. Please update your code to use the technique described in my comment above.

[pbarbiero]

I'm not sure why not being able to run "electron ." inside of atom.io is NOT a bug.
Atom.io is a tool I use to develop; this means I cant use it fully to develop electron apps.

If I do what 50Wliu said every time I open the terminal in atom.io "set ELECTRON_RUN_AS_NODE=", it works fine.

Possibly its an issue with the addon (platformio-atom-ide-terminal) and not Atom.io -- is it possible that environment variables are bleeding across somewhere? Seems strange to me.

Edit: lee-dohm, are you suggesting that your technique in your earlier comment is what should be ported to the addon(s) in question that embed terminals?

[lee-dohm]

I'm not sure why not being able to run "electron ." inside of atom.io is NOT a bug.

From what I can see, it is completely possible to run Electron apps from within Atom using either the technique @50Wliu mentioned or the one I described. So if it truly were "impossible to run an Electron app from inside Atom" then yes, there would be a bug. Since it is possible, there is no bug.

Edit: lee-dohm, are you suggesting that your technique in your earlier comment is what should be ported to the addon(s) in question that embed terminals?

Yes, that is what I'm suggesting.

[pbarbiero]

Just figured I would drop back in, it definitely is not an issue on atoms side. Anyone finding this issue should point the finger directly at how their terminal emulator is passing/handling environment variables.

This specific issue is directly related to the forked terminal not getting a fresh set of env variables (or even setting env variables), and instead picking them up from the node environment, which is why #13624 (comment) works to "fix" the issue.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!