I want to write a good, intelligent installer script for my application. This script must be able to find any old versions of my App no matter where they might have been moved to by the end user. Getting the file path should be adequate I think. Is this possible? I have been experimenting with "path to " but I’m not sure if this is the best implementation. Is there a way to use Spotlight for this, or is there a better way?
Ultimately the goal will be to completely remove the old App so there are no conflicts with the new App.
PS. (Micky San - Hope this is a well formulated question. Thanks for the link on How to ask better questions.)
We deal with this at Freeverse with our updater applications that are designed to locate pre-existing installations of our software. (Typically, we’d just use Installer.app.)
Looking for software by NAME isn’t really how you need to do this, because users can and do change the names of applications on disk. (Sometimes accidentally, sometimes not.) You also shouldn’t only look at /Applications. Users often store programs in their home folders or in other areas of the machine. What you really want is to search for the application via, in order:
LaunchServices bundle identifier.
A quick two or three-level deep search in /Applications, /Shared, and the active user’s home directory. Don’t search for the application’s NAME, however, search for its MacOS executable, which doesn’t get changed by users.
Finally, just prompt the user to locate the previous installation, if you can’t find one programmatically.
Don’t use what you expect the application name to be as a qualifier, basically. The LaunchServices search will find the software in 99.9% of cases, if the user has the ability to see the software at all, but you should have backup plans.
Another concern is that you need to deal with permissions roadblocks. If the user running the update does not have permission to delete the existing software and write the new software, or overwrite it, your installer must not misbehave. You don’t HAVE to go the full mile prompt for authentication, etc., to make it seamless, but your installer must at least not screw up.
If there’s a way you can do this with a standard installer package, DO IT. Don’t roll your own unless you know exactly what you’re doing. I’m pretty sure you can’t do the LaunchServices trick with Installer.app in Panther and Tiger, but you should be able to formulate a decent search for the application’s MacOS executable that will work well on the command-line level.
I took the liberty of writing a command-line tool that uses LaunchServices to locate an application via its bundle identifier (com.apple.safari, for example). You can invoke this in your Installer.app installer script, if you go that way, or if you roll your own solution.
Validate your target before taking action. Maybe even go so far as to tell the user what you’re about to replace, as well. (That’s what we do.) Programmatically, you want to make sure you’re not overwriting the wrong application or files. Verifying the md5 checksum on the MacOS executable of an application package is a good start with this.
It’s not a shell script; it’s a Foundation tool. It also doesn’t use the Finder at all, it uses the underlying Application Services function, which makes it instantly better than any Finder-based solution. It’s more portable, faster, and less prone to Finder problems (like the Finder being busy or insert_reason_here).
Did you download the tool and read the documentation? It will give you the same information as the Finder, you realize. 0 and the application path on success, 1 if unable to locate an application, and 2 if no argument was provided at all.
Thanks for than StefanK. It works perfectly. It isn’t slow on my machine, but I do hear alot about Finder being ,well less that a perfect solution. For now it is probably adequate in my requirement but I am intrigued by Mikey-San’s solution.
If you aren’t familiar with using shell scripts/command-line tools in general, and think the Finder is an adequate solution for your task, you are not ready to ship your own custom installer. I really don’t intend to be mean here, but that would be my opinion at this point.
Sparkle is pretty good. We use a customized version of it for a couple of our applications, and it’s worked well for us. I’m not sure how well it’ll integrate into a Studio project, but it might be a viable solution for him going forward.
Thank you All for the advise. This all helps a lot.
Mickey-San , you are not being mean. I take it you are a full time programmer and as such work with the best your world has to offer. I am not a full time programmer and as such I rely on applescript to merely simplify my workflow. I do however see and understand your remarks. I accept that I am not ready to roll out my own installer using shell scripts just yet, as I mentioned I am still learning.
That won’t stop me from developing , applescript (and Finder) are merely a means to an end at the moment.
Thanks for the link to the technical docs on shell scripting.