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.
Shane, thanks for sharing, but you gave me a scare.
No mention of “Catalina” in the title or body. The small tag line is very easy to miss.
I assume you reported this bug?
Yes, it’s been logged. And I edited the message…
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.”
Radar early; radar often!
Simon
Or as it is now: Feedback early; Feedback often!
Doesn’t have quite the same ring…
I am still not finished with working around all the Mojave limitations… How about:
Can we use OSAXs like Satimage as an “application” or is this killed in Catalina?
Are we still allowed to use Script Libraries?
Can we disable SIP?
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.
It looks like the answer is yes on all counts.
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.
Does one file an AppleScript bug using “Something else not on this list”? Asking for a friend
Yes, sadly. I posted a Feedback item on the lack of AppleScript as a topic — it might be helpful if others did the same.
Have posted the same issues; still not fixed in beta 3, alas.
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).
Or wait and hope it gets fixed…
Urgh… You’re right. One sure sign of an amateur is that he doesn’t see the simple way to get something done. Thank you.
The bug seems to be fixed in the latest developer beta.
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.