Regression related to process.env.PATH

[thomasjo]

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.

[postcasio]

As far as I know, at least on Mac, Atom will correctly read the environment variables if you start it from the terminal. I've just tested:

$ atom
$ PATH=$PATH:/ermahgerd atom

Both of these give the desired result - the first is my full PATH, and the second my PATH with the ermahgerd directory.

However, if you start Atom normally by clicking its application icon, it doesn't inherit your user environment. If Atom is already open, and you use the atom shell command, it will not inherit your user env because it uses the existing Atom process. Did you leave Atom open while testing the shell command?

[thomasjo]

Nope, no running processes. And it used to work fine when started from the .app bundle as well.
Which version of OS X are you running? The only thing that recently changed in my environment was upgrading to Yosemite Beta 1.

[postcasio]

I'm on 10.9.4 here, I can check on Yosemite later.

[thomasjo]

Just tested this on a brand new Yosemite Beta 1 install (clean VM) and I'm seeing exactly the same behavior; all environments variables except PATH get passed to the process. Guess something changed in Yosemite.

[postcasio]

Confirmed on my copy of Yosemite - other environment variables are fine but PATH is not passed.

[robkorv]

I have something simular on Ubuntu 14.04. When started from launcher the path is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games, when started from a terminal it is /home/robkorv/.rbenv/shims:/home/robkorv/.rbenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

This results in linters not working when atom isn't started from a terminal session.
The solution would be to get the exported path from my .bashrc in Atom. Any idea how to do this?

[acrogenesis]

Any fix for this on yosemite?

[wprater]

Ive confirmed this on Yosemite as well, it's breaking the scroll-past-end plugin

[acrogenesis]

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

[brosner]

I did some digging because I'd love to solve this problem. It appears the regression may be within OS X's open command. Which leads me to believe the issue is either in Atom or OS X. I am not familiar enough with how things are split between Atom and atom-shell.

What I did to determine this was to directly call /Applications/Atom.app/Contents/MacOS/Atom --executed-from="$(pwd)" and found process.env["PATH"] was correct.

[DylanLukes]

I have the same issue as well. All variables are passed through except for PATH... Rather odd, but annoying.

I'd like to take a look at this later. It doesn't seem like Atom is paying any attention to launchctl either for me.

@acrogenesis idea does work, and that was the first thing I tried. At least, it works in some cases, such as for making sure binaries are available for subprocessing. For things where the binaries are needed on startup, not so much, due to the timing of the init script.

I would honestly really prefer that the Atom preferences had some way to specify PATH within the application as well. Inheriting from shell is not always ideal, though it is nice with, say, virtualenv.

[anaisbetts]

This is true with all Cocoa applications, not just Atom Shell; Cocoa's environment is separate and sanitized from the environment that Terminal runs under.

[thomasjo]

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: rstudio/rstudio@09c9be1

[joefitzgerald]

+1 - This is affecting https://github.com/joefitzgerald/go-plus. The package relies (pretty heavily) on the PATH to locate go tools. Would love to see a workaround for this.

[zcbenz]

I pushed a fix at atom/atom#4064, can you try if it works for you? I don't have a Yosemite machine currently.

[thomasjo]

@zcbenz As I mentioned on the PR, this works!

[joefitzgerald]

🎆 Looking forward to this 🚢-ing. Do we have an estimated Atom version that will be released with this in it?

[dustinblackman]

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

[dustintheweb]

👍 on the work arounds. FWIW the "open from icon" issue still persists in v0.158

[matthewandrews]

Should this be re-opened? Problem (no path when opening from icon) still exists in v0.160 on Yosemite.

[postcasio]

@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.

[esseti]

I've the problem with Python files, pep8 is not found since the path is not evaluated. how can i fix it?

[sindresorhus]

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

[joefitzgerald]

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.

[thSoft]

Unfortunately this is reproducible again on El Capitan. When launching Atom from GUI, process.env is always:

ATOM_HOME: "/Users/thsoft/.atom"
Apple_PubSub_Socket_Render: "/private/tmp/com.apple.launchd.zFrRYGb4oU/Render"
DISPLAY: "/private/tmp/com.apple.launchd.2Q0RXLd45a/org.macosforge.xquartz:0"
GHC_DOT_APP: "/Applications/ghc-7.10.1.app"
GOOGLE_API_KEY: "AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q"
HOME: "/Users/thsoft"
JAVA_HOME: "/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home"
LOGNAME: "thsoft"
NODE_ENV: "production"
NODE_PATH: "/Applications/Atom.app/Contents/Resources/app.asar/exports"
PATH: "/usr/bin:/bin:/usr/sbin:/sbin"
SECURITYSESSIONID: "186a8"
SHELL: "/bin/bash"
SSH_AUTH_SOCK: "/private/tmp/com.apple.launchd.kDQ8KxAUX5/Listeners"
TMPDIR: "/var/folders/d7/qt541tgd3vzfk32m544ks8mw0000gn/T/"
USER: "thsoft"
XPC_FLAGS: "0x0"
XPC_SERVICE_NAME: "0"
__CF_USER_TEXT_ENCODING: "0x1F5:0x1D:0x2B"

When launching atom from command line:

ATOM_HOME: "/Users/thsoft/.atom"
Apple_PubSub_Socket_Render: "/private/tmp/com.apple.launchd.zFrRYGb4oU/Render"
DISPLAY: "/private/tmp/com.apple.launchd.2Q0RXLd45a/org.macosforge.xquartz:0"
GHC_DOT_APP: "/Applications/ghc-7.10.1.app"
GOOGLE_API_KEY: "AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q"
HOME: "/Users/thsoft"
JAVA_HOME: "/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home"
LANG: "hu_HU.UTF-8"
LOGNAME: "thsoft"
NODE_ENV: "production"
NODE_PATH: "/Applications/Atom.app/Contents/Resources/app.asar/exports"
PATH: "/Library/Frameworks/Python.framework/Versions/3.5/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/usr/texbin:/usr/local/bin:/Users/thsoft/Library/Haskell/bin:/Applications/LilyPond.app/Contents/Resources/bin/:/usr/local/Cellar/llvm/3.3/bin/"
PWD: "/Users/thsoft/Development/DUX/src/test"
SECURITYSESSIONID: "186a8"
SHELL: "/bin/bash"
SHLVL: "4"
SSH_AUTH_SOCK: "/private/tmp/com.apple.launchd.kDQ8KxAUX5/Listeners"
TERM: "xterm-color"
TERM_PROGRAM: "Apple_Terminal"
TERM_PROGRAM_VERSION: "361.1"
TERM_SESSION_ID: "F210E7A3-C894-490F-84D4-5EFCF688D30E"
TMPDIR: "/var/folders/d7/qt541tgd3vzfk32m544ks8mw0000gn/T/"
USER: "thsoft"
XPC_FLAGS: "0x0"
XPC_SERVICE_NAME: "0"
_: "/usr/bin/open"
__CF_USER_TEXT_ENCODING: "0x1F5:0x1D:0x2B"

[PinkyJie]

@thSoft I have the same issue with you, do you have some updates on this?

[aadisriram]

There is a race condition, if I defer the usage of the path by 5 seconds the path is set right! This isn't reproable on every system though. Sometimes it just works even without the deferred access.

[joefitzgerald]

@aadisriram your issue doesn't belong in the electron repo. Feel free to open one in the https://github.com/atom/atom repo. That said, this is by design - see the following for more detail:

• Make updateProcessEnv async and add core:loaded-shell-environment activation hook atom/atom#13200
• Use spawn instead of execFile and clean up running processes on process exit atom/atom#13213