Gitup: Installing command-line tool doesn't work with OS X 10.12 app path randomization

[tfeb]

Installing the command line tools results in a symlink which looks like

/usr/local/bin/gitup -> /private/var/folders/78/msz6jjzs6f304f2n632z3f040000gp/T/AppTranslocation/5A346E3C-1A7A-4AFD-904D-66BD25C03780/d/GitUp.app/Contents/SharedSupport/gitup

That works while a particular instance is running, but then stops working.

This is for a machine running 10.12.3 with GitUp 1.0.6, installed in /Local/Applications (which may be the problem).

[swisspol]

That sounds like "app path randomization" in OS X Sierra is the problem. It's surprising nobody reported an issue with this before.

Very interesting: http://lapcatsoftware.com/articles/app-translocation.html

Under what circumstances does App Translocation occur?

• First, the app must have a com.apple.quarantine extended attribute. If you delete the quarantine xattr, then App Translocation does not occur, and the app will launch from where it was unarchived, like normal.
• Second, the app must be opened by Launch Services. This usually means Finder, but it can also mean open from Terminal, for example. If you launch the app executable directly from bash, on the other hand, App Translocation does not occur.
• Third, the app must not have been moved — by Finder. If you move the app, using Finder, from the app's original unarchived location to another folder, even a subfolder, e.g., ~/Downloads/Test/, then App Translocation does not occur. However, if you move the app using mv from Terminal, then App Translocation will still occur. Normally you would move the app from ~/Downloads to /Applications, and that would cause the app to be launched from /Applications like normal, but the locations of the particular folders don't seem to matter. The mere act of moving the app using Finder stops App Translocation from happening. Indeed, once you've moved the app once, it will no longer experience App Translocation again, even if you then move it back to ~/Downloads.

I think the last option is why most people do not have this problem.

[swisspol]

The solution would be to check the symlink on app launch and fix it if broken.

[tfeb]

I think I have verified the last point. I:

1. moved the app, using Finder, from /Local/Applications to ~/Downloads & back (I originally installed it just with mv from where I unpacked the zip file);
2. nuked the symlink
3. ran it from Finder (or from Spotlight, whatever that's called now);
4. let it install the link.

And it's the right link now.

It might be that the best solution would be to just document that if you put it somewhere you should do that with the Finder? I suspect very few people are as paranoid and shell-focussed as me, and those that are can fix the problem by making the link with ln :-)