4 ms·

These are awesome. I didn't know about many of them. One tiny thing though, at the bottom it says > Recall that OS X apps are not true executables, but actual

These are awesome. I didn't know about many of them. One tiny thing though, at the bottom it says > Recall that OS X apps are not true executables, but actually special directories (bundles) with the extension .app. open is the only way to launch these programs from the command line. Actually, you can launch them in other ways. Example /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/Users/<username>/temp/delmechrome --no-first-run Will start a new instance of Chrome with it's own datastore in ~/temp/delmechrome. add some URL to the end to have it auto launch some webpage. Delete ~/temp/delmechrome to start over.

_jsn 12y ago
Although this technically works, in some cases it may lead to strange bits of misbehavior. (Depending on where you do it, the app may end up in the wrong audit session or mach namespace, and it may also be missing some environment variables that it was expecting). The open command does allow you to specify command-line arguments to pass to the application (via --args), which is generally a safer way to do things.
- TazeTSchnitzel 12y ago
  Some apps will break entirely.
- veidr 12y ago
  But the open command doesn't allow you to pass the environment, and Apple seems hellbent on breaking every workaround they've implemented over the years (e.g. ~/.MacOSX/environment.plist). So, doing Foo.app/Contents/MacOS/Foo is often the only way to launch a GUI app while inheriting the full environment that you have on the command line. I often have to do this to launch various developer tools, and have them be able to inherent important environment variables, e.g. database credentials or secrets,
  - micampe 12y ago
    > But the open command doesn't allow you to pass the environment Uh? I’ve been using open to pass NSZombieEnabled and other debugging stuff to apps all the time and it works. From man open(1): Opened applications inherit environment variables just as if you had launched the application directly through its full path. This behavior was also present in Tiger.
    - veidr 12y ago
      What?! Awesome! I would swear that was once not the case... (checks man page) Opened applications inherit environment variables just as if you had launched the application directly through its full path. This behavior was also present in *Tiger*. Sigh, I'm old...

_jsn 12y ago

Although this technically works, in some cases it may lead to strange bits of misbehavior. (Depending on where you do it, the app may end up in the wrong audit session or mach namespace, and it may also be missing some environment variables that it was expecting). The open command does allow you to specify command-line arguments to pass to the application (via --args), which is generally a safer way to do things.

TazeTSchnitzel 12y ago
Some apps will break entirely.
veidr 12y ago
But the open command doesn't allow you to pass the environment, and Apple seems hellbent on breaking every workaround they've implemented over the years (e.g. ~/.MacOSX/environment.plist). So, doing Foo.app/Contents/MacOS/Foo is often the only way to launch a GUI app while inheriting the full environment that you have on the command line. I often have to do this to launch various developer tools, and have them be able to inherent important environment variables, e.g. database credentials or secrets,
- micampe 12y ago
  > But the open command doesn't allow you to pass the environment Uh? I’ve been using open to pass NSZombieEnabled and other debugging stuff to apps all the time and it works. From man open(1): Opened applications inherit environment variables just as if you had launched the application directly through its full path. This behavior was also present in Tiger.
  - veidr 12y ago
    What?! Awesome! I would swear that was once not the case... (checks man page) Opened applications inherit environment variables just as if you had launched the application directly through its full path. This behavior was also present in *Tiger*. Sigh, I'm old...