The Grumpy Troll

Ramblings of a grumpy troll.

MacOS X: changing argv for launched apps

This is what I did, but it is wrong. Do not do this. See the follow-up post,
http://bridge.grumpy-troll.org/2011/01/macos-x-changing-argv-troll-erred.html


I just had to figure this out for the second time, since I forgot how I did it the first time, however many months ago that was. So, a post to record the results. Note that I'm a Unix person, not a MacOS person and have not yet invested the time that I should have into how my desktop OS functions.

I wanted to try out “Google Body”, which currently requires a Beta version of Google Chrome. So, switched to a Beta and … it still did not work. Check for updates, update the browser (immediately after install!), and still not working. Checking around, I found http://www.khronos.org/webgl/wiki/Getting_a_WebGL_Implementation which showed that I still needed to explicitly pass --enable-webgl on the command-line, as support is not enabled by default. This is reasonable, but could have been better communicated.

Since I don't tend to start MacOS native apps from the command-line, I wanted to change the installed app to do this. The instructions to the OS for how to start an app, and various other important metadata about how to interact with the app, are in a file called “Info.plist”, so for this instance it's “/Applications/Google\ Chrome.app/Contents/Info.plist”. You can edit it as raw XML or invoke open(1) upon it, to bring up the “Property List Editor” app.

Problem number one: despite installing Google Chrome via drag-and-drop as an unprivileged user, somehow the app itself ends up owned as root. The Property List Editor is unable to deal with this except at save time, by throwing an error. Invoking open as root does not fix this, so back to "vi" to edit raw XML it is. (I'm actually relieved that GUI apps do not end up running as root, but the silent transition back to the logged-in user does not aid diagnosis).

Problem number two: there is no plist item which adjusts argv for an invoked application. You just get the “CFBundleExecutable” key, and that's it.
This is trivial to solve: I want to leave the app alone, to permit self-exec to work, so I change CFBundleExecutable's string value to “troll-shim” and create a new file “/Applications/Google\ Chrome.app/Contents/MacOS/troll-shim” (as root, because that's the way the permissions are set up). Give it 0755 permissions. Make it a shell script which dumps some information into /tmp and … it doesn't work.

Problem number three: some part of MacOS (launcher services?) caches the Info.plist data for apps which have been run since boot/login and doesn't spot the change to Info.plist. Solution: move the .app directory aside and back. But you need to invoke the app in the meantime, to invalidate the cache. This doesn't need root, since /Applications is mode 0775 group “admin” and it seems administrator accounts get put in group “admin”.


$ cd /Applications
$ x="Google Chrome.app"
$ mv "$x" XXX.app
$ open -a "Google Chrome"
$ mv XXX.app "$x"


Okay, MacOS will now use our trollish shim script. Let's see what we have to work with … nope, nothing in environ telling what app is being opened; current working directory is the root directory. So, we just have $0 (aka argv[0] ) to work with.

Final result:

#!/bin/sh
RealBin="Google Chrome"
AppDir="$(dirname "$0")"
exec "$AppDir/$RealBin" --enable-webgl "$@"



Comments

Phil P
Manki: yeah, the flexibility of the .desktop Exec is nice and simple.

Alas, for someone new to specifications, reading through the complexity of the quoting requirements to find out what's safe, for dealing with files with whitespace in them, is somewhat daunting and just helps affirm the *nix reputation as user-unfriendly. A shame, since this is an area which shows off just how much friendlier it really is.
Manki
Whoa! Reading this makes me happy about my decision to stick to Ubuntu :)
Categories: MacOSX argv WebGL Chrome GUI