3 ms·

When mentioning `open` they should have noted that `open <file>` will open the given file with its associated app. It’s indispensable.

by donatj 3y ago

lattalayta 3y ago
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
computerfriend 3y ago
Especially open . if you need to drag a file somewhere. One thing that kind of breaks my muscle memory here is the opposite, something like firefox file.html doesn't work and you have to fiddle with the arguments to get open to launch a non-default application.
- alanpearce 3y ago
  If you set alias firefox="open -a Firefox" This will work
- zora_goron 3y ago
  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 -- alias op='open .'
  - ojosilva 3y ago
    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
lloeki 3y ago
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) https://github.com/microsoft/vscode/issues/15452 https://github.com/microsoft/vscode/issues/15452 https://github.com/microsoft/vscode/issues/108804#issuecomment-730296869 https://github.com/microsoft/vscode/issues/108804#issuecomme...

When mentioning `open` they should have noted that `open <file>` will open the given file with its associated app. It’s indispensable.

by donatj 3y ago

When mentioning `open` they should have noted that `open <file>` will open the given file with its associated app. It’s indispensable.

lattalayta 3y ago

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

computerfriend 3y ago

Especially open . if you need to drag a file somewhere. One thing that kind of breaks my muscle memory here is the opposite, something like firefox file.html doesn't work and you have to fiddle with the arguments to get open to launch a non-default application.

alanpearce 3y ago
If you set alias firefox="open -a Firefox" This will work
zora_goron 3y ago
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 -- alias op='open .'
- ojosilva 3y ago
  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

lloeki 3y ago

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) https://github.com/microsoft/vscode/issues/15452 https://github.com/microsoft/vscode/issues/15452 https://github.com/microsoft/vscode/issues/108804#issuecomment-730296869 https://github.com/microsoft/vscode/issues/108804#issuecomme...