A tale of two path separators

The issue arises from macOS's use of both the slash (/) and colon (:) as path separators, inherited from the Mac OS Extended File System (HFS+) and Unix file system (UFS) respectively. When a file with a colon in its name is created, the system translates it to a slash when viewed in certain applications, like the Finder, but displays colons in others, such as BSD programs and Cocoa applications. For instance, a file named "x:y:z.txt" appears as "x/y/z.txt" when listed using the `ls` command. This dual representation can cause confusion, as seen in the example where running `ls` on files named "a:b:c/" and "x:y:z.txt" yields different path separator displays.

The persistence of dual path separators in modern macOS, even after the transition to the Apple File System (APFS) in 2017, is likely due to backward compatibility concerns. APFS replaced HFS+, but the legacy of classic Mac OS and NeXTSTEP's file systems remains. AppleScript, which originated in System 7, still uses colons as path separators and can only provide UNIX-style paths when explicitly requested. This historical context explains why macOS continues to exhibit this behavior, despite the potential for user confusion.

The implications of this dual path separator system are significant for developers and users. For developers, understanding the translation layer between HFS+ and UFS is crucial to avoid issues with file naming and path representation. Users, particularly those accustomed to Unix-like systems, may find the behavior counterintuitive. As Apple continues to evolve its file systems and scripting environments, it must balance the need for backward compatibility with the desire for a more streamlined user experience.