search

adafruit / Adafruit_Adalink

Python wrapper for Segger's J-Link Commander & STMicro STLink V2 to flash various ARM MCUs
MIT License
125 stars 33 forks source link

OSX GUI-based app does not has the same PATH as terminal-based #11

Closed hathach closed 8 years ago

hathach commented 8 years ago

A GUI app in OSX (e.g Arduino IDE) does not the same PATH variable as terminal based, OSX does not pass variables from /etc/profile, /etc/paths, ~/.profile, ~/.bash_rc etc.... Thus adalink does not inherit the correct PATH especially /usr/local/bin used by homebrew, which is required for stlink+opencode.

For issue description

http://apple.stackexchange.com/questions/153402/in-osx-yosemite-why-can-i-set-many-environment-variables-for-gui-apps-but-cann http://stackoverflow.com/questions/25385934/setting-environment-variables-via-launchd-conf-no-longer-works-in-os-x-yosemite

machine-mod solution requires different approaches for OSX version e.g launchd.confonly work with 10.9 and earlier, but Yosemite.

Not sure how to fix it probably, it did a quick hack to append /usr/local/bin insided adalink script.

https://github.com/adafruit/Adafruit_Adalink/commit/a06162d3c8e1835ce7bc68413b3836d8f18f98b1

Please correct it if possible.

tdicola commented 8 years ago

Interesting, it looks like it's an issue introduced with Yosemite. I'm still on Mavericks with my mac but I can at least try a few things to see if explicitly setting the path helps. Let me look more into the workarounds mentioned in what you linked too. Thanks for raising the issue!

tdicola commented 8 years ago

Ouch, yeah reading about the issue more it sounds like a bug in OSX's launchd where it's adding a new path variable instead of replacing the old one when it launches an app. The app will pick up the first path variable it finds and use that one, but this turns out to be the wrong path.

One workaround suggested is to run programs like this with the shell explicitly, like "sh -c 'adalink ...adalink params...'". That's kind of annoying though--I like the fix you suggested, for us to explicitly add to the path when run under OSX. That should at least make things work on Yosemite, and not cause issues on earlier versions that have a good path variable set already. I'll give the change a quick test on my Mavericks machine and merge it in.

tdicola commented 8 years ago

Just committed a fix to modify the path like you suggested. Pull the latest code and let's see if that fixes the issue on Yosemite. It seems to work on Mavericks, but I don't think Mavericks has the same issue.