4 ms·
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
by _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 agoSome apps will break entirely.
- veidr 12y agoBut 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 agoWhat?! 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...