When mentioning `open` they should have noted that `open <file>` will open the given file with its associated app.
It’s indispensable.
replies(3):
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)
https://github.com/microsoft/vscode/issues/15452
https://github.com/microsoft/vscode/issues/108804#issuecomme...