This, IMHO, is the one to bug Apple about. Leenoble_uk asks: "just occurred to me, haven't tried it out but when you have the clipping open in the Finder what services are available?" The answer of course is "none" - notoriously Finder is a Carbon app that offers no services at all (as jmil has noticed), just at the point where they would be most useful. My guess is that Apple wants to shift away from this kind or (or indeed any) use of resource forks in future. textClipping dragation is a deep feature of the Cocoa text framework, but resource fork visibility isn't present in the NeXTStep-inherited FileOpen behaviour. Nevertheless, you have to ask (as some of you have) why this strangely unorthogonal behaviour (a file TextEdit can't see to open but can see as a drag item)? Clearly. This is obviously The Way To Do It (tm) and is a complete response to the plea in my tip for "something more beautiful". textClipping file in TextEdit, you can always drag the file into an already opened TextEdit file. The simple answer from nicksay (also spotted by leenoble_uk) is that although you can't open a. OK, as the author of a dumb "tip" that has raised more questions than it answered, and inspired a very simple answer that shows I'd overlooked the bleedin' obvious, it falls to me, I think, to make amends by summing up the responses here. Or we could try to find out why there's no "Open With Application" choice in the Get Info window. Makes it easy to keep the desktop pattern in view. And I keep a folder in the Dock called Tempfiles for just this sort of random stuff. I keep a Textedit link in the Dock for that very reason. Maybe I'm advertising my ignorance, but on the other hand the process worked just fine. I've been using X since September, have swiped acres of text off my browsers (job hunting, Unix tips, etc.) and didn't even know you could drag text. In Mozilla you can select and copy any text and it will paste into Textedit and look very nice. Or you could stop dragging text, which is the simplest way. Noticed something else as well, which is that when I use Zingg!(if Zingg! hasn't been a tip yet, it should be) to open the file it doesn't offer Textedit as a choice, but does offer Appleworks (I have version 5) as a choice. Try this: Get Info on that file and select preview from the drop-down in the GI box. I'd love someone to step forward and tell me it's all completely unnecessary because I've overlooked something! I'd love to be able to do "open -e -", which would be the standard UNIX way of treating stdin (ie the data passed through the pipe) as the file to open. Transferring the data through /tmp/xxx is a particularly nasty hack. well, perhaps we'd better not get into that here. This in itself isn't ugly, although the use of resource forks in general and in this case in particular are, erm, somewhat. The filename/rsrc hack to get to the resource fork has been discussed here before (thankfully, because that's how I learned about it). But Darwin strings complains that "it is not an object file". First, you shouldn't have to redirect the file into strings (the utility that strips out the binary junk) strings should just take the name of the file as a parameter. This is ugly in at least a couple of ways. % strings /tmp/xxx & open -e /tmp/xxxWow. Open a Terminal and type: % cd directory/with/clipping/ So here's my quick and dirty command line fix. As well as the plain text, there's some binary junk in there too. The trick is that the text is concealed (from normal MacOS X apps and command line utilities) in a resource fork. Read the rest of the article for the workaround solution. You can't copy and paste their contents from Finder, so my task was to find a way of extracting their content into TextEdit.
I guess they're a legacy from Classic Mac, where presumably there are other apps that can read them (SimpleText?). As far as I can make out, only Finder can read them, either in its Inspector or in a Finder window that pops up when you click on the.
textClipping files when you drag text into one of its windows. MacOS X's Finder creates these rather strange. My first hint: very ugly, but offered here in the hope that something more beautiful will come of it.