[_jsn]

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.

[veidr]

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]

> 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]

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...

[TazeTSchnitzel]

Some apps will break entirely.