13.7 File

The built-in file class is AppleScript's way of letting you refer to a file or folder on disk. The literal form is an object string specifier using a pathname string:

file "xxx:Users:mattneub:"

AppleScript pathname strings are Macintosh-type paths, where you start with a disk name, and the delimiter between the disk name, folder names, and filename is a colon. A pathname ending in a colon is a folder or a disk. A partial pathname, one whose first element is not a disk, is taken to start inside the "current directory"; but the interpretation of this notion is unreliable, and partial pathnames should be avoided.

Alternatively, you can specify a file using a Unix-type (POSIX-type) path, where the delimiters are slashes and an initial slash means the top level of the startup disk. To do so, you must ask for a posix file instead of a file. AppleScript presents this, on decompilation or as a value, as a file specifier with the delimiters changed to colons. So, for example, if I write this:

posix file "/Users/mattneub/"

AppleScript changes it to this:

file "xxx:Users:mattneub:"

That looks like an ordinary file object, but behind the scenes it isn't; it's a different class, a file URL (class 'furl'). This 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.

Just to confuse matters still further, some dictionaries mention a file specification class. For example, BBEdit's check syntax command requires a file specification parameter. This is a deprecated, outmoded class (class 'fss '), which the file class replaces transparently. So, this works, even though what you're forming is technically a file object and not a file specification, and a file specification comes back as part of the result:

tell application "BBEdit"
        set r to check syntax file "xxx:Users:mattneub: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. Stick to a file object and let the transparency work for you.

A file object constructed in your script can't be assigned directly to a variable (though, confusingly, a file URL can). Instead, you must assign a reference to the file object, like this:

set x to a reference to file "xxx:Users:mattneub:testing.html"

A file specifier is not resolved until the script actually runs. This means that the file on disk need not exist at compile time. At runtime, however, when the file specifier is handed to some command, either the file must exist, or, if the command proposes to create it, everything in the path must exist except for the last element, the file you're about to create. Otherwise the command will generate a runtime error. We've already met one command that accepts a file specifier to create a file—store script (for example, see Section 9.6.3).

Don't confuse the AppleScript file object with the file class as defined by some scriptable application. For example, the Finder defines the file class with lots of elements and properties not defined in AppleScript itself:

tell application "Finder"
        get owner of file "xxx:Users:mattneub:myFile" -- mattneub
end tell

In that code, the owner property is defined by the Finder. The term file refers to the Finder's file class; the Finder allows you to use a pathname as the name, just as it does for item and folder and other classes. In fact, you can't hand an AppleScript file object to the Finder, as this example shows:

set f to a reference to file "xxx:Users:mattneub:myFile"
tell application "Finder"
        get owner of f -- error
end tell

An AppleScript file object is a viable medium of communication where a scripting addition or scriptable application doesn't define file objects of its own:

script x
        display dialog "howdy"
end script
set f to a reference to file "xxx:Users:mattneub:myFile"
store script x in f replacing yes
tell application "Script Editor" to open f

13.7.1 File Properties

You can obtain a POSIX pathname by forming a file specification and asking for its POSIX path. No element of the pathname need exist. For example:

POSIX path of file "alice:in:wonderland" -- "/alice/in/wonderland"

That, however, is a misuse of this feature; if you want it to behave properly, you need to behave properly. The POSIX path property does some useful things for you; for example, here it supplies the /Volumes directory before the name of a nonstartup disk:

POSIX path of file "main:" -- "/Volumes/main/"

Again, it makes a difference whether you're talking to AppleScript or to some scriptable application. The Finder's file class, for example, has no POSIX path property.

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 scripting addition command:

info for file "xxx: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 obtain a list of the names of a folder's contents with the list folder scripting addition command. There are also commands for reading and writing a file, and there's even some interface for letting the user choose a file (see Chapter 20).