Могут ли быть неканонизированные формы путей файловой системы значительными? (например, «foo // bar», «foo /./ bar» и «foo /../ bar»)

У меня есть сценарий для создания конкретного вкуса кросс-компилятора GCC. Во всем сценарии есть много путей, которые не входят в каноническую форму, например дублирующие разделители путей ( /xxx/foo//bar/yyy ) и вмешиваются в «эти» каталоги ( /xxx/foo/./bar/yyy ).

Я собирался их канонизировать, но мне интересно, важны ли эти формы, а не просто сценарий, который не очищается. В дополнение к только что упомянутым формам мне также любопытно, может ли включение в каталог «вверх по каталогу» также быть значимым в любой конкретной ситуации (например, « /xxx/foo/../bar/yyy вместо /xxx/bar/yyy ). Например, я наткнулся на путь, как /xxx/foo/.//bar/yyy .

  • Захват имени файла, указанного символической ссылкой в ​​переменной
  • Создать новое имя для перемещенного файла, чтобы предотвратить перезапись?
  • awk + паста для очистки PATH?
  • Как правильно и легко настроить `xdg-open` без какой-либо среды?
  • Как читать команды из файла?
  • Поведение команды `du` с флагом` -L`
  • Единственная потенциальная ситуация, о которой я могу думать, – это когда задействованы ссылки. Я могу представить, что форма .. может вести себя по-другому, но как насчет двух других форм выше?

    Возможно, существуют и специфические для платформы причины для построения путей таким образом.?

  • Как удалить пустой каталог (файловая система btrfs)?
  • Поиск разреженных файлов?
  • Почему разрешение отклонено для запуска npm с использованием node-dev?
  • Ограничение доступа к файлам на внешнем диске
  • Как установить PATH или другие переменные среды, чтобы X приложения могли получить к нему доступ?
  • Горячий, чтобы заставить diff проверить ссылку на символическую ссылку?
  • One Solution collect form web for “Могут ли быть неканонизированные формы путей файловой системы значительными? (например, «foo // bar», «foo /./ bar» и «foo /../ bar»)”

    /./ вы всегда должны иметь возможность свернуть / .
    // обычно должен быть разборным, НО я видел, что скрипты configure проверяют его, поэтому я предполагаю, что могут существовать системы, где это не то же самое. Проверьте это, но, наверное, все будет хорошо.
    /../ будет работать только в том случае, если предыдущий каталог не является символической ссылкой (или, я считаю, жесткой ссылкой). Поскольку .. является жесткой ссылкой на родительский каталог, он будет соответствовать этой ветке, а не той, которая используется в текстовом пути. (NB. В вашей оболочке может быть установлено, что она не разрешает символические ссылки на cd s, и в этом случае она войдет в каталог, где символическая ссылка, однако это поведение почти полностью ограничено cd в оболочках с этим набором опций.)

    Используйте readlink -f "$path" , я считаю, что он разрешит все эти случаи должным образом.

    Linux и Unix - лучшая ОС в мире.