3 ms·

This sounds strange; in order to refer to files outside your bundle with a relative path, you would have to be using something like "../../../SomewhereElse/file

This sounds strange; in order to refer to files outside your bundle with a relative path, you would have to be using something like "../../../SomewhereElse/filename.xyz", which is utterly fragile to begin with. I can only assume that this was used to find other applications. Still a fragile dependency; for example, sometimes I put things in "/Applications/Utilities" but sometimes I put them in "/Applications", which means there is no single parent directory that is guaranteed to hold everything. And even if that weren’t the case, the OS has always let you run applications from anywhere you want. Therefore, it has always been possible for apps to break when doing this, and they were just lucky if they ran on a system where it worked. It sounds like in Sierra it will just be much more likely to break.

rarepostinlurkr 10y ago
Thats pretty much exactly what people do. If you are feeling bored, you can check the post and pre flight installer package scripts of some of your most used software. Regex system versions, string compare versions in Ruby (great for "10.9" -> "10.10"), check that their installer package (an OS X binary) is running on... OS X. Sometime developers do this out of ignorance, sometimes its done out of laziness (don't want to do anything platform specific), or business decisions (don't want to do anything platform specific!) or because there was no better way to do it (no supported API). How about applications that have an installer, lay themselves down in /Applications/ then have a folder inside called "Plugins", from which they load relative arbitrary code? More common than you might think!