[chirp_devel] [PATCH] Fix app launching on OS X #4479
# HG changeset patch # User Tim Smith hg@tds.xyz # Date 1486624426 28800 # Wed Feb 08 23:13:46 2017 -0800 # Node ID 8493808da8a1ea40baa5bbf79ea1c33e5646c935 # Parent 0b276128fdd8d7b02aee5d41216d37f11632af0b Fix app launching on OS X #4479
Running chirp .app bundles from ~/Downloads was observed to fail on recent versions of OS X. This is because a OS X security feature called App Translocation is actually executing the .app bundle from a temporary read-only disk image, and the chirp launch script attempts to modify the contents of the app bundle.
This patch avoids modifying the .app bundle when App Translocation is active.
diff -r 0b276128fdd8 -r 8493808da8a1 build/chirp.app/Contents/MacOS/chirp --- a/build/chirp.app/Contents/MacOS/chirp Mon Feb 06 12:09:45 2017 -0800 +++ b/build/chirp.app/Contents/MacOS/chirp Wed Feb 08 23:13:46 2017 -0800 @@ -2,14 +2,18 @@
LOCATION=$(dirname "${BASH_SOURCE}")
-PYTHON=/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python +PYTHON=/opt/kk7ds/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
-if [ -x $PYTHON ]; then +not_translocated () { + security translocate-status-check "${LOCATION}" 2>&1 | grep -q -e NOT -e unknown -e "not found" +} + +if [ ! -x $PYTHON ]; then + PYTHON=/opt/kk7ds/bin/python2.7 +elif not_translocated; then ln -s $PYTHON "${LOCATION}/../CHIRP" PYTHON=${LOCATION}/../CHIRP - export PYTHONPATH="/opt/kk7ds//Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/" -else - PYTHON=/opt/kk7ds/bin/python2.7 + export PYTHONPATH=/opt/kk7ds/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages fi
exec "$PYTHON" "${LOCATION}/../Resources/chirp/chirpw"
# HG changeset patch # User Tim Smith hg@tds.xyz # Date 1486624426 28800 # Wed Feb 08 23:13:46 2017 -0800 # Node ID 8493808da8a1ea40baa5bbf79ea1c33e5646c935 # Parent 0b276128fdd8d7b02aee5d41216d37f11632af0b Fix app launching on OS X #4479
Running chirp .app bundles from ~/Downloads was observed to fail on recent versions of OS X. This is because a OS X security feature called App Translocation is actually executing the .app bundle from a temporary read-only disk image, and the chirp launch script attempts to modify the contents of the app bundle.
This patch avoids modifying the .app bundle when App Translocation is active.
Sweet, thanks! However, is there any reason to just not modify it ever? I'm not sure what I was thinking when I wrote that. It might've been part of some debugging or something.
Anyway, I applied this because it's better, but we might consider removing the modification bit altogether.
--Dan
On Thu, Feb 9, 2017 at 7:01 AM, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Sweet, thanks! However, is there any reason to just not modify it ever? I'm not sure what I was thinking when I wrote that. It might've been part of some debugging or something.
I'm pretty sure the motivation is that OS X is using argv[0] of the Python framework as the name to display in the menu bar. Without the symlink, the app has a "Python" menu with items like "About Python" (instead of "CHIRP" and "About CHIRP").
An alternative is to try and use some undocumented APIs to reset the process name post-launch: https://stackoverflow.com/questions/14122330/programatically-setting-the-mac...
I'm not sure how this is "supposed" to work.
Tim
I'm pretty sure the motivation is that OS X is using argv[0] of the Python framework as the name to display in the menu bar. Without the symlink, the app has a "Python" menu with items like "About Python" (instead of "CHIRP" and "About CHIRP").
Ah, okay, so then we get "python" in the bar if we have to take this frozen-environment path I guess?
I wonder if setproctitle will work on macos for this purpose?
--Dan
On Thu, Feb 9, 2017 at 8:34 AM, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Ah, okay, so then we get "python" in the bar if we have to take this frozen-environment path I guess?
I wonder if setproctitle will work on macos for this purpose?
Yeah, that's right.
I tried it last night and couldn't immediately make it work; if I understand correctly (and I may not), launchd has its own accounting of process names that setproctitle doesn't touch, so ps vs Activity Monitor/the menu bar will report different things after using setproctitle.
I tried it last night and couldn't immediately make it work; if I understand correctly (and I may not), launchd has its own accounting of process names that setproctitle doesn't touch, so ps vs Activity Monitor/the menu bar will report different things after using setproctitle.
Hmm, but launchd is clearly noticing the exec and picking up the switch from sh to python, right? What if we setproctitle and then exec(self) in python?
--Dan
On Thu, Feb 9, 2017 at 9:17 AM, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I tried it last night and couldn't immediately make it work; if I understand correctly (and I may not), launchd has its own accounting of process names that setproctitle doesn't touch, so ps vs Activity Monitor/the menu bar will report different things after using setproctitle.
Hmm, but launchd is clearly noticing the exec and picking up the switch from sh to python, right? What if we setproctitle and then exec(self) in python?
Someone on the Python list points out that the Python framework binary is a member of its own app bundle with its own plists... https://lists.gt.net/python/python/955404#955404
Sure enough, tweaking CFBundleName in /opt/kk7ds/Library/Frameworks/Python.framework/Resources/Python.app/Contents/Info.plist shows that it's controlling the name in the menu bar.
Maybe the symlink has the effect of keeping the framework from finding the Python app plist so that it falls back to argv[0]?
Someone on the Python list points out that the Python framework binary is a member of its own app bundle with its own plists... https://lists.gt.net/python/python/955404#955404
Sure enough, tweaking CFBundleName in /opt/kk7ds/Library/Frameworks/Python.framework/Resources/Python.app/Contents/Info.plist shows that it's controlling the name in the menu bar.
Maybe the symlink has the effect of keeping the framework from finding the Python app plist so that it falls back to argv[0]?
Gah, okay. Well, I don't know much about OSX's stuff here. It'd be nice to figure out a working solution since I think more people are likely to experience this over time, but I'm not likely to dig into it very deep.
Anyway, thanks a lot for what you've done so far. Starting with the wrong name is better than the alternative!
--Dan
participants (2)
-
Dan Smith -
Tim Smith