Installing .app from command line

How can I install an .app from the command line?

I know that some .apps (like Firefox and Chrome) are just directories that can be dragged or copied to /Applications But others aren't. For example, Flash Player.

I'm looking for either a command, like "installer -pkg /path/to/installer.pkg -target /" that works with .apps, or a way to dig out the logic the .app uses when it's double-clicked so I can recreate the installation process myself.

That's nearly impossible since any installer that ships as an app would have a unique file structure inside the bundle (especially since .app installers are non-standard). Is there any app in particular you're looking to do this for?

vansmith said:

That's nearly impossible since any installer that ships as an app would have a unique file structure inside the bundle (especially since .app installers are non-standard). Is there any app in particular you're looking to do this for?

Click to expand...

Why would it be "nearly impossible"? When I double-click on an .app, the GUI installer can somehow manage to figure it out. The method of invocation shouldn't matter unless someone has gone out of their way to make it matter.

And, if for some bizarre reason, Apple has decided to provide different functionality for a CLI tool vs. a GUI tool (which I know they've done before!), how do I find out exactly what the installer is supposed to do? Again, when I double-click on it, the installer is able to extract something that tells it what to do. How do I get that info in a human-readable form? That has to be a standard.

I found an answer for the main app I was worrying about... Flash Player. For the archives:


Another one I'd like to figure out is VLC. This isn't an app I support... one of my users had an old version installed, and a security scan pinged on it for a few known vulnerabilities. I copied the VLC.app over to his system, and the Info.plist shows the new version, but there were several errors that flew by, which gave me the funny idea that it may not work what he launches it We can just reinstall it with the GUI tool, but I'm more interested in the mechanism behind all of this, so the next time I have to deal with an app packaged this way I don't have to start doing a bunch of research for that particular item.

jnojr said:

Why would it be "nearly impossible"? When I double-click on an .app, the GUI installer can somehow manage to figure it out. The method of invocation shouldn't matter unless someone has gone out of their way to make it matter.

Click to expand...

Every app bundle is still a valid app bundle but every .app "installer" is designed differently and may depend on very different file structures within the bundles. Take for instance the part you noted: Who is to say that every app has an -install switch? That could very well be Flash specific.

jnojr said:

Another one I'd like to figure out is VLC.

Click to expand...

As I remember it, this is a regular app bundle so just move it to /Applications.

vansmith said:

Every app bundle is still a valid app bundle but every .app "installer" is designed differently and may depend on very different file structures within the bundles. Take for instance the part you noted:

Code:

sudo /Volumes/Flash\ Player/Install\ Adobe\ Flash\ Player.app/Contents/MacOS/Adobe\ Flash\ Player\ Install\ Manager -install

Who is to say that every app has an -install switch? That could very well be Flash specific.

Click to expand...

Understood... but if I'm at the GUI, and I double-click it, how does it know to use that switch? If I double-click some other .app, how would it know which method to use for it? It can't be magic, or quantum metaphysics. There is a way for the system to know how to handle each package. How does it do that?

It may not be using any switch since the graphical installer may just be doing the copying itself. In other words, the graphical interface invoked when you execute it may not be using the same method that you'd use when executing it from the command line.

Every .app based installer is inherently unique since it's a non-standard method of installing files (pkgs being the standard). As such, they are all going to operate uniquely.