Archive for August 3, 2026

Monday, August 3, 2026

Pasting Quoted Paths and Escaped Terminal Text

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).

NSPasteboard Crashes When Handling File Promises

Wade Tregaskis:

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

[…]

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful.

[…]

SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.

Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).

Apple also told him that NSPasteboard is not safe to use outside the main thread, even though that’s not documented, it’s not @MainActor, and Apple’s own code does do that.