`$PATH` only present when Atom is launched from command line

[dmnd]

When Atom is launched from the command line with atom, it has access to $PATH as defined by the shell so the linter can often find executables.

But if Atom is launched via the dock, Spotlight, Applications folder, or other GUI method, it does not inherit $PATH. This means that linters will fail to find their executables. I bet this problem is behind a lot of the bug reports that see the spawn ENOENT message.

[smlombardi]

This happens to me whether or not i open from command line. Atom 136 and OS 10.10 GM3.

[ryanleary]

Same here. Atom 136 and 10.10 (14a388b).

[smlombardi]

Now I have suppressed the error by reinstalling the gems. But the scss linter is not doing anything.

On Tuesday, October 14, 2014, Ryan Leary notifications@github.com wrote:

Same here. Atom 136 and 10.10 (14a388b).

— Reply to this email directly or view it on GitHub https://github.com/AtomLinter/Linter/issues/150#issuecomment-59048494.

[nsrosenqvist]

Is anyone working on this? It makes the linter-shellcheck plugin useless since everytime a file is opened the console opens up with the error.

[dmnd]

I upgraded to Yosemite and now Atom doesn't seem to inherit the $PATH from the shell I launch atom from. So this issue is now pretty important to fix.

I started working on it a while ago but never finished it. But since my linter is now broken, I'll fix this issue on the weekend.

[bolinfest]

As a workaround for https://github.com/atom/atom-shell/issues/550, consider:

    commandString = 'your command to run a linter';
    if (process.platform === 'darwin') {
      // OS X apps don't inherit PATH, so reconstruct it. This is a bug, filed
      // against Atom here: https://github.com/atom/atom-shell/issues/550
      commandString = 'eval `/usr/libexec/path_helper -s` && ' + commandString;
    }

[dmnd]

Atom v0.142.0 fixed the issue where opening from the command line didn't inherit $PATH. So now this issue only occurs when launching from the GUI. Would still be nice to fix, but not as critical.

[gbersac]

I am on ubuntu and the error fire even when launched from command line, even after adding the :

process.env.PATH = ["/usr/local/bin", process.env.PATH].join(":")

line in init.coffee

[partydrone]

If I launch Atom from the command line, I don't have any issues. But I usually launch it from GitHub for Mac, which causes problems—specifically with rubocop.

[jacebot]

This still occurs when launching from Terminal or Gui on Mac OS (Yosemite)

Uncaught BufferedProcessError: Failed to spawn command pep8. Make sure pep8 is installed and on your PATH Uncaught BufferedProcessError: Failed to spawn command pylint. Make sure pylint is installed and on your PATH

/Users/MyMacUsername/Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:100

[alexbet]

Some thing happens for me as Jacebot above.

Uncaught BufferedProcessError: Failed to spawn command phpcs. Make sure phpcs is installed and on your PATH /Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:104 Uncaught BufferedProcessError: Failed to spawn command phpmd. Make sure phpmd is installed and on your PATH /Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:104 Uncaught BufferedProcessError: Failed to spawn command phpcs. Make sure phpcs is installed and on your PATH /Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:100 Uncaught BufferedProcessError: Failed to spawn command phpmd. Make sure phpmd is installed and on your PATH

[MatthewHerbst]

I also just encountered this issue.

Using: OSX Mavericks 10.9.5, Atom 0.165.0

I launched Atom initially from the dock and edited some files. I then opened another file in Atom from the command line atom myfile and got this error (as well as console opening with the error):

Uncaught BufferedProcessError: Failed to spawn command `shellcheck`. Make sure `shellcheck` is installed and on your PATH 

[davidawad]

Confirmed as well, Ubuntu 14.10 on MacBook Air 2013

[adampats]

Same issue for me. Launching from command line works fine (linter-rubocop loads and functions). However, launching from dock or via Finder file association fails to find rubocop and throws this error:

/Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:
104 Uncaught BufferedProcessError: Failed to spawn command `rubocop`. Make sure `rubocop` is installed and on your PATH

Mavericks 10.9.5 - Atom 0.169.0

[notsuhz]

I'am having the same problem. Using OS X Yosemite. Atom 0.170.

Failed to spawn command luac. Make sure luac is installed and on your PATH

[mjgold]

I'm having this problem, too, when launching Atom from the Mac doc: Uncaught BufferedProcessError: Failed to spawn command rubocop. Make sure rubocop is installed and on your PATH /Applications/Atom.app/Contents/Resources/app/src/buffered-process.js:100 Uncaught BufferedProcessError: Failed to spawn command rubocop. Make sure rubocop is installed and on your PATH

Launching from Terminal loads rubocop correctly.

[andersennl]

+1, Atom Version 0.175.0 OSX Yosemite.

[soulwax]

+1, Atom 0.176.0 Win 10 (should't be a problem), pylint path works from the cmd

[dpflucas]

+1, launching from terminal. Atom Version 0.176.0 (0.176.0), OSX Mavericks.

Failed to spawn command `rubocop`. Make sure `rubocop` is installed and on your PATH

[beck]

Would configuration be an appropriate solution? Allow users to configure linter with a list of bin dirs to append to the PATH.

I recently tried to solve this issue myself system-wide and discovered that OSX 10.10 has made it increasingly difficult to configure your system path for GUI apps.

[dmnd]

@beck Maybe we could use bash --login -c "echo $PATH" then prepend it to the linter command as suggested by @bolinfest. I'm not sure if path_helper is a better option on OS X.

I haven't fixed this because honestly I never run into it. I always start Atom from the Terminal.

[MatthewHerbst]

@dmnd I think many early adopters will start Atom from command line. At the same time, this needs to get fixed so that when Atom is more developed, less technical people can use it no problem. Also, from my personal experience, I have Atom set up as my default text editor, so I often open Atom by double clicking on a file on my desktop.

@beck As per the above, I think users having to configure directories is too complex of a task for the eventual broad audience that we want Atom to have.

[dmnd]

@MatthewHerbst sorry I didn't mean to suggest this shouldn't be fixed. I'm just selfish when deciding where to spend my own time :smile:

I would definitely merge something that fixes this.

[beck]

users having to configure directories is too complex as a task for the eventual broad audience that we want Atom to have

Agreed.

use bash --login -c "echo $PATH"

I like this approach, should work for *nix

How would this work on windows?

[beck]

Side note, the bash login cmd can be fickle if any of the PATH is set using an alias.

Simple example:

alias xcode_path="xcode-select --print-path"
XCODE=`xcode_path`/usr/bin
export PATH="$PATH:$XCODE"

Then you'll see:

$ bash --login -c "echo $PATH"
/Users/doug/.bash_profile: line 114: xcode_path: command not found
/usr/local/bin:/Users/doug/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:....

Even so, it is still useable and better than a manual config.

[dmnd]

How would this work on windows?

Not sure. But I think %PATH% (or whatever it is) on Windows might be available to GUI apps anyway so it mightn't even suffer from this problem. I'm just guessing though.

[ghost]

"Failed to spawn command gjslint. Make sure gjslint is installed and on your PATH" on ubuntu 14.04

i get this with "linter-gjslint" but not "linter-jshint"

[beck]

i get this with "linter-gjslint" but not "linter-jshint"

That's because the jshint linter has extra logic to find the node bin whereas the gjslint linter does not.

[Ryan050]

+1, but launching from terminal works fine

[andronat]

From the terminal is working fine (Max OS X 10.9.5). But not when using the Icon from Dock. Is this a problem of linter or atom itself??

[jmecom]

+1, Atom 0.180.0, OS X Yosemite. Also fails when launching from terminal as well.

[andronat]

Atom 0.181.0, OS X Yosemite. Also fails.

[jtkiley]

+1 Atom 0.181.0, OS X 10.10.

Where is node getting the path from? It's missing one of the paths in /etc/paths, and it doesn't pick up anything in /etc/paths.d/, in addition to not getting anything exported in .bash_profile. I'm checking by looking at the object returned by process.env in the error console.

[jtkiley]

It's ugly, but this (added to init.coffee) is how I'm getting it to find flake8:

process.env.PATH = ["/Library/Frameworks/Python.framework/Versions/3.4/bin",
    process.env.PATH].join(":")

[patmcd]

+1. Atom 0.182.0 OSX 10.10.2

even occurs when launching from terminal.

[rothnic]

Thanks to @jtkiley, this is how I got things working with anaconda on osx:

process.env.PATH = ["/Users/rothnic/anaconda/bin", process.env.PATH].join(":")

[crystoll]

Can verify, I had same issue with gjslint, I added /usr/bin and /usr/local/bin to path in init.coffee script under ~/.atom - and now no errors, it works:

process.env.PATH = ["/usr/bin","/usr/local/bin", process.env.PATH].join(":")

[henridwyer]

I'm getting a similar error: Uncaught BufferedProcessError: Failed to spawn command/Applications/Atom.app/Contents/Resources/app/apm/bin/node. Make sure/Applications/Atom.app/Contents/Resources/app/apm/bin/nodeis installed and on your PATH on Mac OS 10.10.2, since Atom version 0.186, when I launch from command line and from the dock.

node is on my path, at /usr/local/bin, but can also be found at that location.

[paulbaker3]

I was getting a similar error with rubocop: failed to spawn rubocop make sure rubocop is installed and on your path

That was occurring when launching atom from my command line. I verified that $PATH was set properly on my command line.

@crystoll's work around worked for me. Here's my ~/.atom/init.coffee

process.env.PATH = ["/usr/bin",
                    "/usr/local/bin",
                    "/Users/paulbaker/.rbenv/shims",
                    "/Users/paulbaker/.rbenv/bin"
process.env.PATH].join(":")

[jjoekoullas]

@paulbaker3 's ~/.atom/init.coffee worked for me as well.

Here is a more minimal version (with typo correction) which worked for me:

process.env.PATH = ["/usr/bin",
                    "/usr/local/bin",
                    ].join(":")

[MatthewHerbst]

Would something along the lines of the answer provided here work to help alleviate this? The downside is that it would require maintaining each time a plugin is added, updated, or removed.

Further, in Why did my TeX-related GUI program stop working in Mac OS X Yosemite?, there is some background on a further related issue, but what also seems to be some solutions to fix. However, the author warns strongly against the first solution I posted since apparently it changes variables for all running programs.

[julienpa]

Is something planned to fix it someday? I mean, this issue is quite old but the problem seems unchanged; and in some cases (like mine) it makes the software simply unusable (I need linters but most of them throw errors: Failed to spawn command scss-lint. Make sure scss-lint is installed and on your PATH) I tried everything mentioned here but nothing fixed the problem, not even launching Atom from the command line. I am on OS X 10.10.2 with Atom 0.187.0. I'll use another editor in the meantime, but it is a sad and radical solution to an apparently small problem. Thanks for any insight on that!

[MatthewHerbst]

@julienpa Based on the above post of mine, it seams this is more a bug in OSX than in Atom, though there are certainly some potential hacks around the bug. Not sure why it won't work when you start from command line - that seems to fix it for everyone else.

[julienpa]

@MatthewHerbst ah, indeed I had missed the "Yosemite issue" part. Anyway, I was already using some linters on Yosemite before and it was working fine. But I recently added rubocop, scss-lint and haml-lint and none of them work; all of them throw the same errors. I tried launching Atom with the command line from the ~ directory as well as various projects' directories. Same error all the time. Thanks for the reply.

[jtkiley]

@julienpa Have you tried adding to the path in init.coffee like my example above? You'll need the path to the linters you want to use, of course, but it should work.

I agree that it should be a high priority to fix. Linters are really handy, and it would be nice not to have a hurdle for people to use them.

[julienpa]

@jtkiley yes I tried that but it didn't work. Unfortunately I didn't have time to look more deeply into it, and I switched to Sublime Text in order to get the work done without the tons of warnings (I stopped disabling/uninstalling packages in the hope that it would miraculously be fixed one day). Thanks!

[gabll]

+1. I've tried to modify the path in init.coffee, open atom from terminal and from finder, but it's still not working. I'm out of ideas

[laurelnaiad]

What does it mean if you don't even have ~/.atom/init.coffee at all?

$ ls -la ~/.atom
total 32
drwxr-xr-x   10 dmaddox  wheel   340 May 16  2014 .
drwxr-xr-x+  93 dmaddox  wheel  3162 Mar 13 08:57 ..
drwxr-xr-x    4 dmaddox  wheel   136 May 16  2014 .node-gyp
drwxr-xr-x    6 dmaddox  wheel   204 Feb  5 09:39 compile-cache
-rw-r--r--    1 dmaddox  wheel   798 Mar 13 09:08 config.cson
-rw-r--r--    1 dmaddox  wheel  1021 Aug 22  2014 keymap.cson
drwxr-xr-x   32 dmaddox  wheel  1088 Mar 13 09:03 packages
-rw-r--r--    1 dmaddox  wheel   415 Mar 29  2014 snippets.cson
drwxr-xr-x  146 dmaddox  wheel  4964 Mar 12 18:15 storage
-rw-r--r--    1 dmaddox  wheel  1227 Dec  9 18:53 styles.less

And wouldn't it be great if atom itself would do the work (once) to find the node binary and provide a property to its extensions where they can grab it?

My symptoms:

Failed to spawn command /Applications/Atom.app/Contents/Resources/app/apm/bin/node. Make sure /Applications/Atom.app/Contents/Resources/app/apm/bin/node is installed and on your PATH

Is see individual linters have init.coffee, but nothing is out in ~/.atom.

[julienpa]

@gabll @laurelnaiad: yeah... I had to switch back to Sublime Text (which I didn't want to do). There, with a Sublime-Linter package, you just need to install specific linters with npm or gem and done! It's working.

[opennomad]

I've been running just fine for a couple of months now until this morning. I tried various combinations of running from the terminal and setting PATH as suggested above. None of these items fixed my issue.

So I moved my ~/.atom out of the way and started fresh. Installing almost all of the same packages via apm and my linters for shellcheck and ruby are once again working perfectly.

Assuming that it wasn't anything odd I had installed, I moved the new .atom out of the way and put the old one back and moved the compile-cache out of the way. Again my linters are working.

Then for one more try I put the original compile-cache back and things are still working.

Sure feels like a gremlin in there somewhere. At any rate I'm back up and running and perhaps some of my shenanigans might help others.