Julian Kahnert recently introduced me to
xed, a command-line built-in that opens individual documents in Xcode. You give
xed the name of a file (or files) and presto, it launches in my favorite IDE.
There’s some intriguing flexibility to
xed. You can request that Xcode remains in the
--background or specify a
--line number to select once open. The line number request affects the last file in the invocation. In addition to passing it files to open, you can
--create new files with the contents of stdin: promising for scripting and code-gen utilities.
If you pass
xed promises to create a “new empty unsaved file”, without involving stdin. Unfortunately, in my experiments with it over the past week, I’ve found that while it’s very good at opening a single file, complex commands can sometimes confuse the poor geriatric utility.
xed was introduce way back in Xcode 3.0 and it kind of shows its age at times.
Even just limiting my
xed use to opening a file for editing, it’s a neat little discovery for me, so thank you Julian!
Our discussion arose out of my own little utility
xcopen, which I put up on Github. Mine looks in the working directory for an
xcproj and then opens it. (I got tired of either working through the file completion, when there’s always a subdirectory with the same name as the
xcproj or having to open Finder and then launch.)
I really like the idea behind
xed and I’m half tempted to extend the feature set in
xcopen using AppleScripting to get the promise of
xed with a more reliable delivery platform.