kokarn / atom-grunt-runner

Run Grunt tasks from Atom.
MIT License
31 stars 23 forks source link

Uncaught Error: spawn ENOENT #2

Closed tvooo closed 8 years ago

tvooo commented 10 years ago

If I don't have anything entered in the PATH field of the package's settings, I get this error message in the console: Uncaught Error: spawn ENOENT.

If I have a wrong path entered in the PATH field, I get the proper error message (as should happen for the above case, as well).

BTW: Sublime Text has this problem, and it appears to affect Atom as well. If I start Atom via iTerm (or any environment with the correct PATH), the PATH is set correctly and I don't need to set in manually. If I start Atom from Alfred or the Dock instead, this is not the case. Might be my environment, though, but in case someone comes up with the same problem, you can point them to it.

blvz commented 10 years ago

@tvooo Take a look at this comment.

JaKXz commented 10 years ago

I'm seeing the same issue... I tried to set process.env.PATH like the comment says but no luck. I'm not having any issues with Sublime Text though.

blvz commented 10 years ago

@JaKXz Try to compare the process.env.PATH when launching Atom from the command line with the one when launching from the icon.

joseym commented 10 years ago

6 month old (feature breaking) bug with no solution or even acknowledgment from the creator?

I'm assuming this is a dead project and am removing this potentially super-useful package from my installation...

Sad.

joseym commented 10 years ago

It definitely lacks the same "wow" potential as being able to select between grunt tasks but noseglid/atom-build is a working solution for anyone else experiencing these problems with grunt-runner and have yet to find or be presented with a solution.

maxkorp commented 10 years ago

So this seems to be related to a few things. First, if you're starting atom from the command line, it gets path correct, but in mac at least, starting it spotlight or mission control sets it somewhere else. Adding /usr/local/bin/ (the default path for when you do npm install -g grunt-cli) to the path in the grunt-runner settings seems to get it to run grunt (for me). However, its running the wrong gruntfile. Trying to figure out which, I suspect its trying to run the grunt file for grunt-cli, but i'm not sure.

maxkorp commented 10 years ago

Interesting, that was a typo in my gruntfile (I think i hit a key when i thought i had my terminal focused). Updating the path to grunt cli in the plugin settings worked, as well as loading atom in the project directory from the command line. Looking in to setting up the paths for launching things from spotlight/mission control. I might modify the readme a bit and submit a PR.

maxkorp commented 10 years ago

Also note that reloading the application once youve opened your project (ctrl+cmd+alt+L) will fix issues where its looking in the wrong directory.

jjgonecrypto commented 10 years ago

I've found the same as @maxkorp - refuses to work when loading through Spotlight unless you reload it as mentioned. In both cases setting the path in InitConfig is required (/usr/local/bin for me). It seems that it has to do with Atom loading the project on startup, vs being told to open it via cmd+O which you have to do when opening via Spotlight.

maxkorp commented 10 years ago

Correct. I have a few changes locally that fix this, but I haven't gotten to clean them up yet so I'm not comfortable filing a pull request (The ones in my commits mentioned above dont work at all, but i took a fresh stab at it).

I'll try to get that this weekend. I basically default to include /usr/local/bin, as well as reinitializing when the project changes (theres an event for that). As it stands, the functionality would just keep grunting project a if you opened from project a in the terminal, but then used another plugin to change to project b. Changes fix that as well.

kokarn commented 10 years ago

Ah, this would be very welcome! I've encountered the same error simply by first having an empty tab and then opening a project.

maxkorp commented 10 years ago

Yeah so the issue is that upon initialization of the package, it grabs the current project directory and caches it. It also tries to load the grunt tasks for the project, and cache those. When you load up via finder or spotlight, the project directory is undefined. Simply reloading that info on the project changed event or whatever its called takes care of it. Its a simple enough change, my coffeescript is just rougher than all get out.

kokarn commented 8 years ago

@maxkorp Is this still an issue?

maxkorp commented 8 years ago

I don't know, unfortunately. I haven't been using grunt in a real way for 6+ months now, as I have everything automated.

kokarn commented 8 years ago

Hmm, i'll close this for now then. If somebody else reports it, i'll reopen. Thanks for the quick response!

maxkorp commented 8 years ago

:+1: No problemo!