electron: Regression related to process.env.PATH

I’m assuming this is controlled by Atom Shell and not Atom, so I’m reporting it here; process.env.PATH does no longer match the user’s $PATH environment variable. It is instead some form of system default, “sanitized” value.

This regression seems specific to OS X. I have verified process.env.Path is not “sanitized” on Windows 8.1 running Atom v0.120.0. The inconsistency might be accidental because on Windows the environment variable is named Path and not PATH. I have not tested to see if the regression also occurs on any GNU/Linux distributions.

Tried to scan through the recent commits to figure out when this regression got introduced, but had no such luck… perhaps it’s related to the recently upgraded Chromium?

All other environment variables are correctly read (and passed to) Atom. Which means that this works

$ EVERYTHING=/is/awesome atom

in that the variable can be read in Atom via e.g. console.log(process.env.EVERYTHING), whereas this

$ PATH=$PATH:/ermahgerd atom

does not. Regardless of what I do, console.log(process.env.PATH) always displays /usr/bin:/bin:/usr/sbin:/sbin.

Update:

Tested with Atom v0.120.0 and Atom built from source, running on OS X Yosemite Beta 1.

Installing fresh copies of OS X 10.9.4 and 10.10 in VMs now, to see if I can reproduce the old behavior and the regression.

About this issue

Original URL
State: closed
Created 10 years ago
Comments: 28 (7 by maintainers)

Commits related to this issue

Comment Out Test Impacted By Yosemite PATH Regression - https://github.com/atom/atom-shell/issues/550 — committed to joefitzgerald/go-plus by joefitzgerald 10 years ago
Fix error which occurs when closing .js tabs. The cause of the error is undefined @flowPath, which happens in at least the following two cases: - flow is not installed - flow is installed, but proce... — committed to martomi/linter-flow by martomi 9 years ago
Fix for missing $PATH on OSX re https://github.com/atom-community/linter/issues/150 / https://github.com/atom/electron/issues/550 — committed to josip/atom-instant-build by josip 9 years ago

Most upvoted comments

For anyone looking for a fix for getting the path when run as an app on OS X, see fix-path.

+10

sindresorhus on Dec 4, 2015

My fix was setting manually my PATH in the init script process.env['PATH'] ='YOUR PATH'

If you don’t know your path you can get it by running echo $PATH on your terminal

acrogenesis on Sep 29, 2014

We could also adapt the approach taken in https://github.com/atom-community/environment (I.e. Launch the user’s shell to get a sane environment of the user launches an electron app via Finder, Dock, Spotlight, open, et al.

joefitzgerald on Dec 6, 2015

@matthewandrews I think that’s a separate problem - OS X doesn’t use your bash profile when launching applications from the Dock. See http://serverfault.com/questions/16355/how-to-set-global-path-on-os-x for a good way to set your PATH for that case.

postcasio on Dec 17, 2014

Not the best with Coffescript, but for those needing a quick fix check the gist and throw it in your init.coffee. Works on Yosemite just fine, should work on Linux if needed. Uses my zsh config, but should work with anything you set it to. 😃

https://gist.github.com/dustinblackman/db56445e5d649ccbd2b2

dustinblackman on Nov 12, 2014

I pushed a fix at https://github.com/atom/atom/pull/4064, can you try if it works for you? I don’t have a Yosemite machine currently.

zcbenz on Nov 5, 2014

We’ve never had full access to e.g. $PATH when executing from outside of a shell, but starting in Yosemite, inheriting $PATH when launching apps from the terminal has regressed. I’ve confirmed this with several developers on other OS X applications (RStudio, iTerm2, and others). A bug has been opened with Apple, but this might never get fixed. In particular the problem seems to be with setenv(3) in correlation with NSTask, but I haven’t got the specifics of the bug report.

There are workarounds however. Really hope Georg Nachman doesn’t mind that I share this here, but here’s what he does

Prior to fork()ing, I copy the contents of the environment into a dictionary (this removes duplicates). Then I convert it back into a char**. After fork, I set environ=newEnviron and then do execvp().

This is how they fixed the issue in RStudio: https://github.com/rstudio/rstudio/commit/09c9be12b12cf030051d5da2b0820df6cb7e7c49

thomasjo on Nov 4, 2014