`$PATH` only present when Atom is launched from command line
dmnd opened this issue · 73 comments
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.
This happens to me whether or not i open from command line. Atom 136 and OS 10.10 GM3.
Same here. Atom 136 and 10.10 (14a388b).
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
#150 (comment).
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.
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.
As a workaround for electron/electron#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;
}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.
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
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.
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
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
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
Confirmed as well, Ubuntu 14.10 on MacBook Air 2013
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
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
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.
+1, Atom Version 0.175.0 OSX Yosemite.
+1, Atom 0.176.0 Win 10 (should't be a problem), pylint path works from the cmd
+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
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.
@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.
@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.
@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 😄
I would definitely merge something that fixes this.
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?
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.
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.
"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"
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.
+1, but launching from terminal works fine
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??
+1, Atom 0.180.0, OS X Yosemite. Also fails when launching from terminal as well.
Atom 0.181.0, OS X Yosemite. Also fails.
+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.
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(":")
+1.
Atom 0.182.0
OSX 10.10.2
even occurs when launching from terminal.
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(":")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(":")
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/node is 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.
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(":")
@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(":")
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.
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!
@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.
@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.
@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.
@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!
+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
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.
@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.
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.
As jjoedouglas said, just edit ~/.atom/init.coffee.
Go to menu Atom > Open Your Init Script, just add this lines at the end of the file:
process.env.PATH = ["/usr/bin",
"/usr/local/bin",
].join(":")
Works for me.
Just FYI, under Linux/Ubuntu I had to add /bin to the path:
process.env.PATH = ["/bin",
"/usr/bin",
"/usr/local/bin",
].join(":")
Otherwise certain elements of the settings page wouldn't work correctly, such as searching for a package to install (would throw an error saying it could not find uname)
Cheers
Dan
Adding
process.env.PATH = ["/usr/bin",
"/usr/local/bin",
].join(":")
to .atom/init.coffee fixed the issue for me.
👍
Using Atom 0.198.0 on Windows 8.1 Professional together with XAMPP. Trying to use linter-php.
Have entered the following line at the end of .atom/init.coffee
process.env.PATH = ["C:/PortableApps/XAMPP/App/xampp/php", process.env.PATH].join(":")
With this entered, and if the linter detects an error, I get this error message:
'php' could not be spawned. Is it installed and on your path?
If so please open an issue on the package spawning the process.
with a "Uncaught Error: spawn php ENOENT" in the log file.
I tried adding the following lines to the .atom/config.cson file:
"linter-php":
phpExecutablePath: "C:/PortableApps/XAMPP/App/xampp/php/"
in addition to the entry in the .atom/init.coffee file that I mentioned above, but that didn't eliminate the problem.
In other words, the problems that others have mentioned in this thread seem to still be occurring in the version of the linter that I'm using on Windows 8.1, and the proposed workarounds don't seem to solve the problem.
UPDATE (2015-05-15) - Checked to see if this problem could be addressed by adding the directory with the php executable to the overall system PATH variable. Doing that does, in fact, address the problem - the linter then works correctly. The PATH variable can be changed using "View Advanced System Settings", which brings up the "System Properties" dialog, and the PATH variable can be changed for either the user or the system by clicking on the "Environment Variables" button and editing the PATH variable contents and then saving the changes.
Path should contain only directory, right? not a binary like php, so try this:
process.env.PATH = ["C:/PortableApps/XAMPP/App/xampp/", process.env.PATH].join(":")@Ricain - Thank you for the suggestion. However, C:/PortableApps/XAMPP/App/xampp/php/ is, in fact, the directory where the php executable php.exe is located. That is, the fully specified path and file name of the php executable is
C:/PortableApps/XAMPP/App/xampp/php/php.exe
As I mentioned in the update to my original post, the problem can be solved by placing the path for the php executable in the system PATH variable. But that really shouldn't be necessary given the configuration and init script options that are supposed to allow you to specify where the executable is located.
Has anyone else noticed that when you checkout a different branch (in a project dir already opened in atom), the path is destroyed? Thus in turn, breaking linter.
Hey guys,
process.env.PATH = ["/usr/bin",
"/usr/local/bin"].join(":")
also tried
process.env.PATH = ["/usr/bin",
"/usr/local/bin",
process.env.PATH].join(":")
to my ~/.atom/init.coffee didn't work. I also noted that Atom when started from command line works fine but didn't when started from my Xubuntu panel, so I edited the Atom shortcut (laucher) in my panel and changed the command from /opt/atom/atom %F to bash --login -c "atom", as suggested above.
Now all my ruby related packages are working!
It seems that init.coffee isn't run until after packages are loaded, so if one of your packages tries to spawn a shell command that's not on your default $PATH then it still doesn't work. As fas as I can tell the only alternative in that case is tweaking the launcher to run Atom from within a shell environment.
I'm running OS X 10.10.5 and Atom 1.0.9 and I'm having this issue both launching from GUI and terminal. Are there any other solutions other than editing the init.coffee because that doesn't seem to work for me.
@rennsport why not specify a path to the executable in linter config?
@steelbrain So my linter directory is /Users/[user]/.atom/packages/linter what file would I need to edit because none are standing directly out as a config file.
@rennsport You won't need to edit any file for this, just goto settings view, the linter provider you want to specify executable for, and there should be a field for it.
@steelbrain My linter provider doesn't seem to have those options in settings
@rennsport that is the base linter you are pointing at, by a "provider", I meant packages like "linter-jshint", "linter-eslint" and "linter-flake8"
@steelbrain I feel slightly less capable now as I linked this project within the project itself without realizing it haha. Sadly however, the actual linter provider does not have such settings unless I'm missing something obvious again.
Edit: Under the configuration I am told I need to set the Executable Path, but there is no option for that and I'm not sure what file I would add it to.
@rennsport It does have that setting and it's called executable, see https://github.com/AtomLinter/linter-pylint/blob/master/lib/main.coffee#L9
but if you are unable to see it for some reasons, then I would suggest you try this and let me know the results of it
mv ~/.atom ~/.atom-bkp
apm install linter
apm install linter-pylint
@steelbrain I now see said settings. Maybe the theme I was using hid them? Anyways I have now gotten around the first error, and I have a second (I apologize for my novice understand of this). Error: "Traceback (most recent call last):" I can show the full error in a pastebin or something similar.
@rennsport can we please chat in the atom slack or at least in a separate issue, I have to open up this super-long page each time and tons of people are notified each time via email/push.
In linter-rubycop plugin,
I have rubocop command set like this.
/Users/anil/.gem/ruby/2.2.4/bin/rubocop
But when I open Ruby project from Atom menu File -> Open.., it gives me following error
Error: /Users/anil/.rubies/ruby-2.2.4/lib/ruby/2.2.0/rubygems/dependency.rb:315:in to_specs': Could not find 'rubocop' (>= 0) among 229 total gem(s) (Gem::LoadError) Checked in 'GEM_PATH=/Users/anil/.gem/ruby/2.2.0:/Users/anil/.rubies/ruby-2.2.4/lib/ruby/gems/2.2.0', executegem envfor more information from /Users/anil/.rubies/ruby-
But when I open project from command like like atom . I don't see this error.
My Atom version is 1.3.2 and I am using El Capitan.
This is an issue that is planning on being solved in Atom (see atom/atom#4126), with a temporary workaround planned in steelbrain/atom-linter#62 for linter plugins that utilize the atom-linter package. For any that don't they will need to work around this limitation on their own.
I'm locking this issue as it hasn't been the proper repository for this issue for a very long time in the first place, and any further work on resolving the issues presented here will be done in the linked issues.
For any users on OS X until a workaround for Apple's "interesting" decision is put in place, the simplest method is to launch Atom from a terminal that has a full environment set up using atom ..
Here's an announcement for you, we have recently published a release of atom-linter (npm helper module for linter providers) that now automatically determines $PATH even if atom is not launched from terminal. Therefore all linters using it for execution, once updated to the new version, will be working consistently from both dock and CLI.