Comment by donatj
3 years ago
When mentioning `open` they should have noted that `open <file>` will open the given file with its associated app.
It’s indispensable.
3 years ago
When mentioning `open` they should have noted that `open <file>` will open the given file with its associated app.
It’s indispensable.
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:
Why this matters, e.g with vscode:
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...
Especially
if you need to drag a file somewhere. One thing that kind of breaks my muscle memory here is the opposite, something like
doesn't work and you have to fiddle with the arguments to get open to launch a non-default application.
If you set
This will work
I use `open .` to open up a Finder window of the directory I'm currently in using Terminal so frequently that I've set up an alias for it --
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.
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