Restart your computer, reset Automation security settings, and run your scripts afresh is good basic troubleshooting advice, but it doesn’t sound like that’s the cause.
I’ve not touched AI’s AppleScript interface in over a year (recent projects have all been in JSX), so haven’t been following exactly what’s changed and when, but this may be related (“foo” is me):
stackoverflow.com/a/58856316/7926970
Basically, the Illustrator application dates back to Mac OS 7 days, and some parts of its guts use pre-OSX, pre-sandboxing, macOS-defined datatypes and APIs (e.g. Carbon Alias and File Managers) that Apple has long since deprecated and will eventually phase out. Therefore Adobe needs to replace old AI code that uses those old, dying APIs with new code that uses modern, supported macOS APIs. Unfortunately, AppleScript, being another System 7-era technology and long neglected by Apple, is still using some of those old dying datatypes itself, and while it supports some (though not all) of the newer types this support is kludgy, inconsistent, worryingly brittle, appallingly documented. Plus, half of these datatypes don’t play well with the other half.
Now add some current AI engineers, who probably have little-to-no familiarity with AppleScript or Illustrator’s support for it, typing to upgrade neglected quarter-century old code so that it works well with modern macOS sandboxing, and a small but ardent base of heavy AppleScript users who rely on this whole house of cards to keep on working while all this chop and change is going on.
I did observe at the time that while the old AppleScript “file specifier” type still in use in some parts of AI (e.g. “file path” properties) was horrendously obsolete and long overdue for replacement, but using plain old strings to describe file system paths was a really bad idea, precisely because there’s no 100% reliable way to distinguish a string specifically describing a file path from a string that contains any old text. (This is the whole reason for having different datatypes in the first place.) Plus, the way that AppleScript performs string↔︎file type coercions (badly, inconsistently, and non-reversibly) means that older AppleScripts that used “file-like” objects would break where path strings are now expected, and vice-versa.
The appropriate change I said at the time would be for these properties to use “POSIX file” («class furl»), since that makes it clear what type of data it is, even in a command such as “do javascript” that accepts either a value that points to a JavaScript file or a string containing JavaScript code. So it may be that later 24.x releases and 25.0 changed again from using path strings to another “file-like” type, but with all these rolling changes—and with AppleScript’s own support and documentation being horribly confusing—it wouldn’t surprise me if it all gets tangled up in itself, particularly if AI is also trying to be “helpful” by still allowing scripts to pass file paths as plain strings. Which, as I say, is liable to turn into an error-prone mess for any command that accepts code files and code strings interchangeably.
To be clear, even if the above is the cause of the problem (which it may or may not be), this is Apple’s fault for running AppleScript into the ground over the last 15 years, not Adobe’s for trying (and failing) to make the resulting confusion work. Honestly, I’ve built the most advanced Illustrator automation on the planet, and I did using AI’s AppleScript interface (though not AppleScript itself) because when it works it is incredibly powerful, elegant, and a pleasure to work with (much nicer than JSX!). And even I’m counting the days till Adobe ships UXP for Illustrator now, as AppleScript infrastructure looks increasingly like a bitrotten liability, not a platform on which to build a future.
--
TL;DR: Working with files in AppleScript is a nightmare, period, and not getting any better.
1 Correct answer
21
Replies
AdChoices