On Sun, 15 Sep 2013 12:46:29 +0200 Jacob Carlborg <d...@me.com> wrote:
> On 2013-09-15 11:52, Nick Sabalausky wrote: > > > Windows actually does the same thing, except the filename *is* the > > command: > > > > $ file.txt > > > > And yea, either way, "open file.txt" or "file.txt", it is kinda > > nice. Although I find I use it very rarely, oddly enough. > > I mostly use "open" to open a directory in the file browser: > > $ open . > > That's especially useful when opening hidden folders. Yea, that one I picked up a few weeks ago when I first tried to test the release builder script on OSX. I couldn't for the life of me figure out how to get Finder to show the temp directory, so a little bit of web searching led me to that. But I didn't know it worked for files, too. The windows version is (for directories only): $ explorer . > > Hmm. What's the benefit over just doing this?: > > > > $ /Applications/TextEdit.app foo.txt > > $ /Applications/TextEdit.app foo.txt > -bash: /Applications/TextEdit.app: Is a directory > > .app "files" are bundles, that is, directories which Finder and other > tools treat specially. > > The actual executable is located at > /Applications/TextEdit.app/Contents/MacOS/TextEdit > Ahh, ok. I knew about bundles, but I didn't know the command line didn't do the same special handling for them, too. > In the case of TextEdit, running: > > $ /Applications/TextEdit.app/Contents/MacOS/TextEdit foo.txt > > Will complain that foo.txt doesn't exist. The shell will also wait > until the application terminates. Running through "open" the shell > will not wait for the application and it will open the document > properly. > I see, that's interesting. So it does have a special way to launch an app asynchronously without the "&" at the end of the command line. Does it also gag stdout/stderr? Am I correct in assuming "open" is specifically an OSX thing, and not something inherited from BSD?