In case you’re thinking of taking the plunge into 10.15, there seems to be an issue where POSIX path is returning incorrect results for directories. For example:
POSIX path of path to desktop
Returns:
"/Users/shane/Desktop:/"
That colon shouldn’t be there, and this is likely to break an awful lot of scripts.
FYI, I asked an Apple employee yesterday if there is anything wrt AppleScript in 10.15. His reply was:
“No new features, a number of smallish bug fixes. There are two significant (potential) compatibility issues:
1. The dedicated System partition means many system folder locations have changed. If you’re hard-coding them, stop, and use “path to” instead.
2. “do shell script with administrator privileges” has a new implementation that improves security. However, it also precludes presenting UI from within the privileged command. Break the command apart so the privileged part is as small as possible.”
So far, the Feedback system is giving me even less information, with outright two errors. Now I need to find if there is a process for giving feedback about Feedback.
I doubt that’s necessary. What I’ve seen so far is that while the new Data volume that contains the user-modifiable part of the boot volume lurks in a new location (/System/Volumes/Data), Apple has taken care to match all the old paths up with it, so that you can find the SAME item now at both the old path (such as /Users/yourname/Desktop) as well as at the new path (/System/Volumes/Data/Users/yourname/Desktop). So, it appears all the known paths are still there, on purpose. But maybe the Apple guy meant something else?
Huh, I wonder what that means - My app Find Any File restarts itself (i.e. the entire app) with that old and deprecated API to get root access to all files, and yet its UI is still functioning well on 10.15b1.
Here is a clumsy workaround for this bug, only practical if your script doesn’t coerce a lot of POSIX paths. It’s based on this page, with one slight modification:
This is the handler (slightly modified from the original (I couldn’t make it work in my scripts until I added “as string”)
use framework "Foundation"
property NSString : a reference to current application's NSString
on remove:remove_string fromString:source_string
set s_String to NSString's stringWithString:source_string
set r_String to NSString's stringWithString:remove_string
return (s_String's stringByReplacingOccurrencesOfString:r_String withString:"") as string
end remove:fromString:
To use it, immediately after you get a POSIX path, add this:
if myPosixPathVariable contains ":" then
set myPosixPathVariable to my remove:":" fromString:myPosixPathVariable
end if
This is obviously a great waste of time, and anyone who knows anything about AppleScript can write something better, but it seems to get the job done while the bug remains unfixed.
The catch with that is that : is a valid character in a POSIX path — that’s what a / in an HFS path gets converted to. You’re probably better off using something like this:
if myPosixPathVariable ends with ":/" then
set myPosixPathVariable to (text 1 thru -3 of myPosixPathVariable) & "/"
end if
Still not guaranteed, but a bit safer (and simpler).
Yes, along with the bugs in path to resource and path to temporary items. I suspect the bug where aliases sometimes appear with POSIX paths and are unusable is also fixed.
And Automator actions are finally getting legal UTIs.
But the bug where aliases on APFS disks don’t track their location when moved is alive and kicking.