Anthony Reimer:

When you are shell scripting or working in Terminal, sometimes you want a quicker way to enter the path to a file or folder, particularly if you have already navigated to it in the Finder. One way that works in Terminal is to drag the file or folder from the Finder onto the Terminal window, which then types the path into the current command. However, another method was introduced in El Capitan (OS X 10.11) that allows you to copy the full path onto the clipboard.

In Finder, you can hold down Option and choose Edit ‣ Copy Pathname.

Starting in macOS Sequoia, copying the path to the clipboard using the method described generates a path that can be directly pasted into the Terminal or a script and be interpreted as that path without further manipulation.

It adds single quotes and or escapes characters, but only if necessary.

There are certainly some people who are unhappy with this change in behaviour but most Mac Admins will not be among them.

You can get the unescaped path via AppleScript.

Anthony Reimer (via Miles Wolbe):

Graham Pugh pointed out that if you have text on the clipboard, you have the option of pasting that text “escaped” in Terminal. Simply copy the text from whatever source you choose (e.g., the output of an AutoPkg run, where paths are not escaped), then in Terminal choose Edit > Pasted Escaped Text or use the shortcut Command-Control-V.

[…]

As a bonus, this concept can be applied to a tip I learned from Armin Briegel a few years ago, namely that if you select something in Terminal that you want to then paste into the current shell command, you can skip the copy-paste dance and instead just press Command-Shift-V to do it in one step (or if you prefer menus, Edit > Paste Selection). If you add the Control key to that sequence, the text pasted is escaped (Edit > Paste Escaped Selection or Command-Control-Shift-V).

SmallCubed:

AppleScript support makes it possible to automate message processing and connect Maven with other applications such as Hookmark, EagleFiler, Filemaker, and DEVONthink. Almost anything you normally do by interacting with MailMaven’s interface, such as searching for messages, tagging, filing, flagging, and composing, can now be automated.

[…]

AppleScript makes it possible to control Maven using the natural language capabilities of AI assistants such as Claude and ChatGPT via a MCP server. […] To connect AI assistants to Maven, we have developed a basic MCP server that implements over 25 end points. This can be downloaded and installed from our MailMavenMCP repository on GitHub. With the MailMavenMCP you can instruct your assistant to access and process messages without the need to write any AppleScript. For example, if you want a summary of the conversation you are reading, simply instruct the assistant to “Summarize the conversation of the currently selected message in MailMaven”.

The AppleScript support is really impressive. It’s extensive and thoughtfully designed and implemented, with performance in mind:

A query is a temporary AppleScript-based smart mailbox that can are used to locate and examine/manage messages.

Using queries is much faster than iterating through messages in mailboxes because it uses Maven’s internal mechanism for locating messages that smart mailboxes use.

Depending on the scope and nature of an iterative search which can take seconds, if not minutes to process, queries are almost instantaneous. Moreover, queries have the ability to sort messages and filter duplicates.

[…]

Scripts can be performed from Maven’s inbox, outbox, and keystroke rules via the Run AppleScript Rule action.

I’m excited to see a new app leaning into this old technology, which remains unsurpassed. EagleFiler is already taking advantage of the AppleScript support to enable importing messages (with all their metadata) just by pressing a hotkey. I also expect it to enable some great new features in future versions of SpamSieve.

Previously:

• EagleFiler 1.9.21
• MailMaven 1.0

SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:

• I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.

• The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.

• Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".

• Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().

• I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.

• I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.

• There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.

• The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.

Previously:

• Xcode 27 Announced
• SpamSieve 3.3
• Swift Proposal: Precise Control Flags Over Compiler Warnings
• Swift at 10

Hartley Charlton:

Apple today announced that users can now describe a shortcut in natural language, with Apple Intelligence automatically building the automation in the background.

Marcus Mendes:

Users can simply describe what they want, such as “when I’m leaving work, text my wife with my expected ETA,” and Shortcuts will actually build the shortcut to make it work.

This sounds great in that I find creating shortcuts annoying. It’s not always clear which building blocks I should be using, and stringing them together properly seems tedious and fiddly. On the other hand, I dislike how AppleScript doesn’t get first-class support for the functionality and triggers that are available to Shortcuts.

Simon B. Støvring:

Data Jar got sherlocked, and that genuinely makes me happy.

Simon B. Støvring:

Apple should let users filter out and maybe even rewrite notifications from any app using Shortcuts.

[…]

The new notification automation trigger in Shortcuts is super cool. As far as I can tell, it won’t let me modify the notification content or filter out notifications based on the content, but it’s still a quite powerful addition.

[…]

Third-party automation triggers in Shortcuts are now possible. Sort of.

Just send a notification containing data meant for the new notification trigger to consume.

Anders Borum:

iOS 27 allows 3rd party shortcuts actions to run for longer than 30 seconds making me publish 2 actions that have been hidden behind feature flags for years.

Create cloud servers, run commands and destroy them again right from Shortcuts.

Previously:

• Apple Intelligence in appleOS 27

Update (2026-06-26): Jason Snell:

This is as close as we’ve come, across 40 years, to the original dream of putting computer power in the hands of everyone. You can literally tell your device what you want it to do, and when—”every morning show me my to-dos and calendar events for the day”—and it will generate a program to do it and a schedule to run it.

[…]

Yes, there are lots of limitations. Describe a Shortcut doesn’t work with third-party apps, only Apple’s own stuff (at least, for now). It can sometimes get confused, especially with complex queries. And it has an interesting tendency to kick things to the Use Model action—why am I not surprised that an AI model likes to build Shortcuts that themselves use AI models?

But when it works, which is most of the time, it’s magical.

Simon B. Støvring:

Shortcuts on macOS Golden Gate is… Something.

Dedicating that much window space to a larger shortcut tile and a text field feels incredibly wasteful.