Different PATH with fixPath compared to $PATH in terminal?

[sindresorhus]

Different PATH with fixPath compared to $PATH in terminal?

[sindresorhus]

@erikmellum Just run it in the node repl: $ node

I have a feeling this might be that you have those $PATH additions exported in .zshrc and not .zshenv. Is this the case? The .zshrc file is only loaded in interactive terminals, which exec isn't, and you should not be used for exporting environment variables, like $PATH. http://zsh.sourceforge.net/Intro/intro_3.html

[sindresorhus]

No idea. I'll look into it.

// @silverwind Any ideas?

[silverwind]

Hmm, a execFile bug/oddity perhaps? Does this give the expected path?

childProcess.execSync(process.env.SHELL + ' -c \'echo $PATH\'').toString().trim()

edit: fixed quoting

[erikmellum]

If you just log the result directly you get nothing (surprisingly). I checked out in debugger and saw the following:

http://prntscr.com/7r955s

[silverwind]

Try again, I forgot quotes around the -c arguments earlier.

[erikmellum]

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin is the output.
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Users/guest/.rbenv/shims:/usr/local/opt/nvm/v0.10.35/bin:/Users/guest/.bin:/usr/local/lib/node_modules is the expected output

If we compare from the expected output from the actual, we can see it stops at /Users/guest. I am suspicious that there is some strange permissions on that folder that break it. The place that logic doesn't hold up, is the fact that this is a string.

[erikmellum]

@sindresorhus good suggestion about executing in the repl. Secondly, you are correct. I only have the PATH exported in .zshrc. I will add the .zshenv file and update you with the results.

[silverwind]

I think @sindresorhus is on the right track. Though, incorrect usage of .zshrc for PATH additions is pretty common, we should handle it for the common shells. zsh has an -i option to force an interactive shell. Does this work @erikmellum?

childProcess.execFileSync(process.env.SHELL, ['-i', '-c', 'echo $PATH']).toString().trim()

[erikmellum]

You bet your sweet brilliant booty's it works. I can't thank you two enough. The best I can do is pay it forward to others as a thank you - which I will. In celebration here is the output from my app.

/Users/guest/.rbenv/shims:/usr/local/opt/nvm/v0.10.35/bin:/Users/guest/.bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/lib/node_modules

Thanks to you both @sindresorhus @silverwind

[silverwind]

Imho, this case should be handled by this module. Opened sindresorhus/shell-path#3

[erikmellum]

@sindresorhus I still get an ENOENT error when I spawn from my application on OS X. I have the PATH correctly set now with your help, and the folder I'm executing it in certainly exists. Any idea what sort of context could cause the error to still be thrown despite those two variables being set appropriately?

[sindresorhus]

@erikmellum What are you trying to spawn? Can you share some code?

[erikmellum]

@sindresorhus The application is going to be an extension to the foundation-cli that lets you set up new project workspaces in a GUI environment (many designers have a hard time learning the command line - this reduces the barrier). So some example commands that work in electron-prebuilt, but not in the OS X package are:

spawn('npm', ['install'],{cwd: project.directory});
spawn('bower', ['install'],{cwd: project.directory});
spawn('gulp', {cwd: project.directory});

I fix the process.env.PATH using the method above childProcess.execFileSync(process.env.SHELL, ['-i', '-c', 'echo $PATH']).toString().trim() and project.directory is a folder that I git clone template projects into. It exists long before these spawn commands are executed so I know its not a race condition.

[sindresorhus]

Probably related to you using nvm as it puts the binaries in a location that is only available to the subshell it launches on startup. I've seen this before in max-mapper/monu#21 (comment). I would open an issue on nvm about exposing a way to get the path to the binaries from outside nvm. Would be happy to implement support in shell-path if so.

[erikmellum]

Thanks for the information. I will follow up on that issue. Your help is much appreciated.

[erikmellum]

@sindresorhus I am trying to locate an example where someone has successfully spawned off gulp the way I want to. The closest I could find in your awesome-electron repo was your repo gulp-app. The interesting thing is the method you use there (By joining dirname) works in electron-prebuilt for me, but does not produce stream output when bundled up as a package.

The other method I used was putting gulp as the script for npm start. The problem here is that calling npm.commands.start does not allow access to a stream. I put in issues to nvm (to programmatically expose the bin folder) and for npm (to emit events when using npm programmatically so users can latch onto whenever data is produced on a stream), but I'm not holding my breath for those fixes. I doubt they will get implemented so I'm searching for a solution within my control.

Do you know any projects that utilize node_modules that I can reverse engineer? I'm trying to document my problems / progress here: https://discuss.atom.io/t/not-possible-to-spawn-npm-modules-from-electron-package-in-os-x/18905

My hope is to come up with a good precedent so people can solve this more easily in the future. If I could get RVM to implement the shell path that would be most ideal I think. I'm up to do these patches myself if there is no other alternative.

[erikmellum]

@sindresorhus SOLVED

gulp=spawn(process.env.SHELL, ['-c', 'cd ' + project.directory + ' && gulp'])

OR

childProcess.execFileSync(process.env.SHELL, ['-c', 'launchctl setenv PATH "$PATH"'])

launchctl setenv PATH "$PATH"

Fixes this issue. I'd recommend adding the launchctl code to fixPath. It should solve this issue for others automagically.