Два разделителя пути в macOS: наследие от классической Mac OS и Unix

macOS поддерживает два разных разделителя пути: слеш (/) и двоеточие (:). Слеш используется в Unix-подобных системах, двоеточие, в классической Mac OS. Эта особенность возникла при слиянии двух операционных систем с разными файловыми системами: HFS+ (двоеточие) и UFS (слеш). Система автоматически переводит один разделитель в другой в зависимости от контекста.

Особенность видна в AppleScript, который восходит к System 7 и использует двоеточие как основной разделитель пути. При этом слеш в имени файла будет отображаться по-разному: для BSD-программ как двоеточие, для приложений Carbon как слеш. Даже после замены HFS+ на APFS в 2017 году двойная поддержка разделителей была сохранена для обратной совместимости с огромным объёмом существующего ПО.

Ключевые факты

  • macOS содержит два разделителя пути из-за исторического слияния Mac OS и NeXTSTEP
  • Файловые системы HFS+ и UFS использовали разные разделители (двоеточие и слеш)
  • Одно и то же имя файла может отображаться по-разному в зависимости от приложения
  • AppleScript использует двоеточие как основной разделитель из-за наследия System 7
  • APFS сохранил двойную поддержку для обратной совместимости с существующим ПО

Ред. Решение, принятое при слиянии операционок десятилетия назад, до сих пор живёт в вашей файловой системе и иногда здоровается двоеточием вместо слеша.

Почему это важно

Двойная система разделителей, это следствие архитектурного выбора Apple при объединении двух операционных систем. Разработчики должны понимать, что одно и то же имя файла может интерпретироваться по-разному в зависимости от того, через какой API осуществляется доступ. Это может привести к неожиданному поведению и ошибкам при работе с файловой системой, особенно в скриптах и инструментах, которые используют разные API.

Ред. «Одно имя файла, два значения, зависит от API» это формулировка, после которой хочется переименовать всё в snake_case и больше никогда не открывать Finder.

Кому это важно

В первую очередь это касается разработчиков, работающих с macOS, особенно тех, кто пишет утилиты командной строки или системные скрипты. Администраторы систем и инженеры DevOps должны учитывать эту особенность при работе с кроссплатформенными инструментами. Также это актуально для разработчиков, использующих AppleScript или интегрирующих приложения, которые работают с путями файлов на разных уровнях.

Ред. Список тех, кому это важно, заканчивается на «использующих AppleScript», и здесь почти у каждого читателя загорается лампочка соболезнования.

Как это применить

При работе с файловыми путями на macOS следует явно запрашивать POSIX-пути, когда это необходимо. В AppleScript можно использовать функцию POSIX path() для получения пути в стандартном формате Unix. При разработке кроссплатформенных приложений необходимо помнить о возможности существования файлов с необычными символами в имени. Тестирование должно включать проверку работы с файлами, содержащими потенциально проблемные символы.

Ред. Совет «явно запрашивайте POSIX-путь» переводится как «не доверяйте операционке самой решить, что вы имели в виду». Здравый принцип шире одного macOS.

Можно ли доверять

Информация основана на официальной документации Apple и исследовательской статье инженеров Apple, представленной на Usenix 2000. Описанное поведение подтверждено практическими примерами использования ls, Finder и osascript. Apple документировала эту особенность и по-прежнему сохраняет двойную поддержку в современных версиях macOS, что указывает на намеренный архитектурный выбор, а не на баг.

Ред. Документ Apple сами назвали «user-visible schizophrenia», так что доверять можно: они честно знают, что сделали.

Риски и подводные камни

Основной риск заключается в неожиданном поведении при создании или обработке имён файлов. Файл, созданный через графический интерфейс Finder, может быть недоступен или неправильно отображаться при обращении через командную строку. Скрипты и инструменты, не учитывающие эту особенность, могут столкнуться с проблемами совместимости. Для критичных операций рекомендуется использовать явное преобразование путей и тестирование с реальными сценариями использования.

Ред. Файл, который виден в Finder и пропадает в терминале, это не баг, а повод поверить в призраков (и в обратную совместимость с 1991 годом).

«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.»

— Apple engineers, Usenix 2000