More than that, it sends a message to launchd/the app instead of forking on the spot.
Sadly the app does get the shell's environment and it can't be disabled:
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.
Why this matters, e.g with vscode:
- ensure vscode is fully closed
- enter project directory, something sets vars in your shell (you manually or automatically via direnv)
- code .
- vscode process now has the env from the shell it was started
- open another directory from the UI
- vscode forks and inherits from its parent process, thus the other project window has the original shell's env
- go to another directory
- code .
- vscode finds out it's already running, forks and opens another window. this window has the original shell env
- fully quit vscode and reopen it, but via the app in /Applications
- vscode opens, now has a blank environment for its main process, and forks form there to restore previous windows, which now lack the environment they had
It's a) completely inconsistent and b) dangerous: imagine the original shell had a setting or secret in an env var that was shared to the second project (e.g virtualenv, deploy target, deployment key...)
The same issue can happen with other apps but also tmux (the tmux daemon is spawned from the first tmux command, and then subsequent sessions from tmux-server; doing it another way is possible but nontrivial)
It took me a while but I finally got open to open folders in a new Finder tab instead of opening a new window each time.
function opent () {
what=${1:-`pwd`}
what=$(cd "$what"; pwd)
osascript -e "tell application \"Finder\"
activate
set t to target of Finder window 1
set toolbar visible of window 1 to true
end tell
tell application \"System Events\"
keystroke \"t\" using command down
end tell
tell application \"Finder\"
set target of Finder window 1 to POSIX file \"$what\"
end tell" > /dev/null
}
## opens current dir
$ opent .
## same
$ opent
I also find myself using open -n -a <application> to open a new separate instance of an application if I want to copy settings from one file to another or work on two files with separate instances of a program
It’s indispensable.