AppleScript_ The Definitive Guide - Matt Neuburg [128]
The file URL in the first line has been turned into a file object specifier, and now AppleScript complains about the first line! You can avoid a lot of this madness by using a variable instead of a literal in your specifier:
set s1 to "/Users/mattneub"
set x to POSIX file s1
set s2 to "feathers:Users:mattneub"
set y to a reference to file s2
The string used to form a file URL specifier must not contain a colon. If it does, various bad things can happen, depending on the version of AppleScript and the environment: an incorrect pathname might be generated (a bug in AppleScript), or the script could fail to compile or to run (silently, in the Tiger version of Script Editor—a bug in Script Editor).
The string used to form a file URL specifier need not denote an existing path:
set s to "/alice/in/wonderland"
POSIX file s -- file "feathers:alice:in:wonderland"
You may regard this as a bug, but in any case, don't use such a string in the first place. Similarly, don't form a file URL specifier with a string that does not start with a slash; partial pathnames are unreliable.
The file URL class pops up in various contexts, lurking behind the file class. For example, the choose file name scripting addition is documented as returning a file object, and appears to do so, but in reality it's a file URL.
A few old applications still expect or generate a deprecated, outmoded class called file specification (class 'fss '). For example:
tell application "BBEdit"
set r to check syntax file "feathers:Users:mattneub:Desktop:testing.html"
class of result_file of item 1 of r -- file specification
end tell
You can even form a file specification object using an object string specifier, but don't. They can behave oddly; that's why they are deprecated. The file class replaces the file specification class transparently. So stick to a file object and let the transparency work for you.
File Properties
The following is a property of a file, an alias, or a file URL:
POSIX path
This is the Unix-type pathname of the file. No element of the pathname need exist, but you should not deliberately misuse this feature: apply it only to valid files. When you do, it is very helpful; for example, it supplies the /Volumes directory before the name of a nonstartup disk.
POSIX path of file "alice:in:wonderland" -- "/alice/in/wonderland", a misuse
POSIX path of file "gromit" --"/Volumes/gromit/"
That is the only file property, but there are some scripting addition commands (see Chapter 21) that supplement the file classes in valuable ways. For example, you can obtain a host of useful information about a file, such as its creation date, whether it's invisible, whether it's a folder, how big it is, what application opens it, and lots of other cool stuff, with the info for command:
info for file "feathers:Users:mattneub:someFile"
The result comes back as a record, which is easy to read and well documented in the StandardAdditions dictionary, so I won't go into details here. You can also obtain a list of the names of a folder's contents with the list folder command. There are also commands for reading and writing a file, and there's even some interface for letting the user choose a file.
File Classes in Applications
Don't confuse the AppleScript file object with the file class as defined by a particular scriptable application. For example, the Finder defines a file class, but it's a completely different file class. One way you can tell this is that, on the one hand, it has no POSIX path property, and on the other hand, it has lots of elements and properties not defined in AppleScript itself. For example:
tell application "Finder"
get owner of file "feathers:Users:mattneub:myFile" -- mattneub
end tell
You couldn't do that without the Finder, because the owner property is defined by the Finder. It's true that the second line appears to contain a file object specifier, but it doesn't. Rather, this is a name element specifier, just like saying folder "Mannie". It just so happens that the Finder lets you use a pathname