Могут ли быть неканонизированные формы путей файловой системы значительными? (например, «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 .

  • Исполняемый файл не может быть найден
  • Несколько приложений, которые записывают один и тот же файл в общем разделе NFS
  • linux как cd к родительской папке, если она перемещается через символическую ссылку
  • Утилита командной строки для визуализации того, как быстро растет файл?
  • Использовать альтернативы или добавить в PATH?
  • Установить максимальное количество процессов, начатых incrond
  • Единственная потенциальная ситуация, о которой я могу думать, – это когда задействованы ссылки. Я могу представить, что форма .. может вести себя по-другому, но как насчет двух других форм выше?

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

  • Как удалить папку, начинающуюся с «$»?
  • Дисковое пространство ext4 не восстанавливается после удаления файлов
  • Греп от конца файла до начала
  • Как написать содержимое файла в новый файл, удалив повторяющиеся строки
  • Удалите определенное расширение из всех файлов в каталоге
  • аудит системных вызовов symlink / symlinkat здесь не работает
  • One Solution collect form web for “Могут ли быть неканонизированные формы путей файловой системы значительными? (например, «foo // bar», «foo /./ bar» и «foo /../ bar»)”

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

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

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