A question about file paths this week made me reflect again on how seldom this subject is covered adequately in most AppleScript books, and yet how challenging it can be. There are many different types of file paths, and this is an area where scripts are frequently in need of updating due to macOS changes.
My number one rule for years: When it comes to file paths in AppleScript, use whatever works. Old-timers like me still wish for the days of Jon’s Commands, which freed us from this worry. But I digress…
I’ve now made freely available the Quick Reference Guide which Shane Stanley and I created for attendees of our AppleScript Pro Sessions training events. Although it has been several years since it has been updated, I must say it is still a damn fine little reference. Here’s the link:
Do you want more proof that file paths as always changing? As I’m typing this I realized the current guide does not include the “furl” type of path now often needed. Plus, I actually ran across an instance when a Microsoft Outlook app needed a URL path for attachments. But I’m too lazy to fix that now. Be happy with free.
There’s an entire chapter in Learn AppleScript 3rd edition (ch. 17) that attempts to bring sense to this subject. However, the entire topic is an absolute dumpster fire, mostly down to poorly managed language evolution and general failure of joined-up design. (Compounded more recently by Apple’s larger security evolution roadmap which is not exactly perfectly executed either, but let’s not go there as well.)
Outside of Finder, which has its own way to reference filesystem objects, a good general rule of thumb is to use POSIX file objects and POSIX-style path strings (except where unsupported by certain ancient gnarly OS9-era Carbon-based apps). HFS paths are long deprecated and cause serious problems if you have more than one volume of the same name. Additional good rules of thumb:
Use pathString as POSIX file coercions to convert path strings to file objects, not POSIX file pathString (which, being an object specifier, can get problematic inside tell contexts).
Use POSIX path of fileObject to convert POSIX file (and alias) objects back to path strings.
If you need to keep track of a file while moving or renaming it, coerce from POSIX file to alias (also long deprecated, but what can you do).
Be aware that the object returned by pathString as POSIX file is actually of class «class furl», not POSIX file as you’d expect (one of its failures of joined-up design). This really only matters if you’re getting a value’s class property to check its type (i.e. class of fileObject is «class furl») or are just wondering what you’re looking at in result logs, although it’s generally better practice to try to coerce a given value to POSIX file and catch any coercion errors that arise.
…
BTW, I wrote a perfectly cromulent File library years ago which included commands for common path manipulations: join path, split path, etc. One of an unofficial “standard library” that I did try getting the community and Mark to adopt and share at the time; alas, AppleScript culture has never valued formal code reuse so that went nowhere. Moving all the ugly error-prone crap behind a nice clean AS interface would be the sensible thing to do. i.e. If an API is too complicated and inconsistent to document clearly and concisely then redesign and rewrite it until it is, and then explain that. (LAS taught me this lesson the hard way; one of the reasons I make my own end-user languages now.) Anyway, it’s still there if anyone wants to use it.
One last thought: Until such time as Apple provides us all full clarity on its own future Automation roadmap (hopefully this year or next), you might consider writing new code in a form that will be easier to migrate to other languages, all of which use POSIX path strings, just by way of insurance.