AppleScript_ The Definitive Guide - Matt Neuburg [37]
Tip
A resource-fork script file and a data-fork script file look exactly the same from the outside, so to distinguish them you have to be sneaky. You can do it using the command line in the Terminal; an easy GUI-based alternative is HexEdit (http://www.ifd.com/hexedit).
The wholesale deprecation of resource forks early in the history of Mac OS X has now, ironically enough, been countered by a move in the opposite direction, generalizing the resource-fork mechanism to allow multiple, arbitrarily named forks. See John Siracusa's article on file metadata in Tiger: http://arstechnica.com/reviews/os/macosx-10.4.ars/6.
Two kinds of problem have resulted from this proliferation of compiled script file formats . The first has to do with backwards compatibility. A script bundle can't be opened on any system before Panther (Mac OS X 10.3). A data-fork file can't be opened on most pre-Mac OS X systems. But those are the only two formats that Apple's Script Editor can create, so any compiled script file created by Script Editor will lack some backwards compatibility.
(To be precise about data-fork file compatibility, a data-fork file created by the current Script Editor can usually be opened by Script Editor 1.8.3 on a pre-Mac OS X system. But if you go back any further, to Script Editor 1.4.3—which was the standard as recently as the early days of Mac OS 9—it won't be able to open it.)
The second problem is that some applications in common use predate the development of one or both of the more recent formats, or for some other reason fail to take proper account of the multiplicity of possible formats. So, for example, Entourage X can't deal with data-fork scripts, and Entourage 2004 can't deal with script bundles. (In fact, iTunes doesn't deal very well with script bundles either.) NSAppleScript (used by Cocoa applications to load compiled scripts) can deal with resource-fork files in Tiger, but couldn't do so in Jaguar (Mac OS X 10.2). This puts the onus on the programmer to make sure the intended script file format will work properly in the particular context where it is to be run, while longing for the good old days when a script was a script was a script.
Run-only Scripts
Normally, a compiled script actually contains two kinds of information:
The tokens (bytecode) needed to run the script
Further information needed to decompile the script and display it to the user
For example, let's say you put a comment into your script. This comment is nothing that the runtime can execute; that's what it means to be a comment. But clearly you don't want this comment thrown away merely because you compile the script; the compiled script therefore retains it, so that when the script is decompiled, you can still read the comment. Similarly, the names of variables are intended entirely for humans; as far as bytecode is concerned, it would be sufficient to assign them numbers, and that's probably what AppleScript bytecode does. But you want to be able to read your variable names the next time you edit the script, so they are saved as part of the compiled script, even though they aren't needed for execution.
A compiled script can optionally be saved as run-only . (In Script Editor, this option appears as a checkbox in the Save dialog; in Script Debugger, choose File → Export → Run-Only Script.) In this case, the tokens needed merely to decompile the script and display it to the user are not written into the resulting compiled script file. This makes the compiled script file much smaller and probably causes it to run a bit faster, but it cannot be opened for display or editing.
Warning
Be careful when saving a script as run-only. If you have not retained