A Dual-Separator Saga: The macOS Path Paradox

I was recently reminded that macOS permits the creation of files that seem to contain slashes in their names when viewed through the Finder. For instance, I created a folder using the "New Folder" utility and a text file via TextEdit, both of which appeared to have / characters in their titles.

Despite knowing the technical explanation, this visual glitch still feels counterintuitive.

The Reveal: ls vs. Finder

If you are confused by this behavior, a simple terminal command provides the answer. By running ls, the truth is revealed:

$ ls
a:b:c/
x:y:z.txt

Depending on your perspective, these files contain either colons or slashes. This occurs because macOS utilizes two distinct path separators: the slash (/) and the colon (:).

A Legacy of Two Worlds

This duality is a remnant of the architectural marriage between two ancestral systems: the classic Mac OS and the Unix-based NeXTSTEP. To merge these, Apple engineers had to ensure compatibility between two very different file systems:

File System	Origin	Path Separator
HFS+ (Mac OS Extended)	Classic Mac OS	Colon (:)
UFS (Unix File System)	NeXTSTEP	Slash (/)

The evolution of this integration can be visualized as follows:

The "Schizophrenic" Translation Layer

A Usenix 2000 paper authored by Apple engineers delves into the friction of combining these environments. They describe a specific phenomenon regarding the translation layer:

[The translation layer] can create a user-visible schizophrenia in the rare cases of file names containing colon characters, which appear to Carbon applications as slash characters, but to BSD programs and Cocoa applications as colons.

Modern Encounters: AppleScript

You are most likely to run into the colon separator today when using AppleScript, which traces its lineage back to System 7 (an era where only HFS+ mattered).

$ which osascript
/usr/bin/osascript

$ osascript -e 'tell application "Finder" to get (path to me)'
alias Phoenix SSD:usr:bin:osascript

While AppleScript defaults to the legacy format, you can explicitly request a POSIX-style path:

$ osascript -e 'tell application "Finder" to get POSIX path of (path to me)'
/usr/bin/osascript

The Persistence of the Past

In 2017, Apple transitioned from HFS+ to the Apple File System (APFS). However, the dual-separator logic persists. While not explicitly documented, it is highly probable that this is maintained for backward compatibility; changing the fundamental path logic would likely break a massive volume of existing software.

Final Reflections

The reason this "slash-in-filename" quirk is so jarring to me is that I entered the world of programming after Unix-style filesystems had achieved total dominance. In my mental model, the path logic is simply:

$\text{Path} = \text{Directory} + \text{Separator} (/) + \text{Filename}$

I used to think Windows was the "weird" one for utilizing the backslash (\). In reality, various systems have employed a wide array of separators throughout history. It is only the current Unix hegemony that makes the macOS approach seem strange. In an alternate timeline, seeing a forward slash in a filename would be completely unremarkable.

---

Summary Checklist:

• Identify the Finder/Terminal discrepancy.
• Trace the origin to HFS+ and UFS.
• Note the role of the translation layer.
• Observe AppleScript's legacy behavior.
• Acknowledge the shift to APFS.