<p dir="auto">When I put Atom in my Apple Dock and clicked on the icon Atom started successfully but couldn't find needed programs in my PATH. I've spent sometime finding a possible solution.</p>
<ol dir="auto">
<li>Instead of having a binary in the Atom.app/Contents/MacOS use your script Atom.app/Contents/Resources/app/atom.sh.</li>
<li>The script needs 2 changes:
<ul dir="auto">
<li>change for the new location of the binary</li>
<li>change the first line of the script from:<br>
#!/usr/bin/env bash<br>
to:<br>
#!/usr/bin/env bash -l</li>
</ul>
</li>
</ol>
<p dir="auto">This seems to start Atom from a bash shell that runs the ~/.profile script first allowing all of the environment variables to get set and made visible to Atom.</p>
<p dir="auto">OS X still does not have shared global environment variables. But it does help establish the login environment variables for atom including PATH.</p>
<p dir="auto">I've made a new application just for your script as my current work around.</p>
<p dir="auto">Thanks,<br>
Mark Zander<br>
<a href="mailto:tarzander@hotmail.com">tarzander@hotmail.com</a></p>
<p dir="auto">When Atom is launched as an application, it doesn't get the user's PATH, because it was launched by <code class="notranslate">launchctl</code>. This means that packages like <a href="https://github.com/rgbkrk/atom-script">script</a> and <a href="https://github.com/willwhitney/hydrogen">hydrogen</a> have to tell the user to launch Atom from the command line. Some packages (like hydrogen) can't even be installed without the PATH because their dependencies use native extensions built with <a href="https://github.com/TooTallNate/node-gyp"><code class="notranslate">node-gyp</code></a>. There exist tools such as <a href="https://github.com/sindresorhus/fix-path"><code class="notranslate">fix-path</code></a>, but they clobber the user's PATH even if they've set something on purpose (with e.g. a virtualenv).</p>
<p dir="auto">Having access to the user's PATH will become more and more important as people build packages that interface more deeply with languages, other tools, and the user's environment. Forcing the user to configure each package with complete paths to the binaries it needs is possible, but inelegant, and becomes intractable with general-purpose tools.</p>
<p dir="auto">This seems like a clear situation where making this change to Atom itself would dramatically simplify life for many packages and eliminate many bugs arising from poor attempts to capture the PATH.</p>