Как Linux обрабатывает несколько последовательных разделителей пути (/ home //// username /// file)?

Я работаю над сценарием Python, который передает расположение файлов в подпроцесс scp. Это все нормально, но я нахожусь в ситуации, когда я могу конкатенировать путь с именем файла, так что в пути есть двойное /число. Я знаю, что bash не волнует, если у вас есть несколько разделителей файлов, но мне интересно, как именно это исправить. Это bash, который лишает лишних /s или это вообще не имеет значения?

Я спрашиваю, потому что это сэкономит мне несколько строк кода для проверки дополнительных /s при конкатенации. Я знаю, что это не имеет большого значения, но мне тоже любопытно. У меня есть сценарий bash, в котором есть строка cd //usr(вместо cd /usr), что, по-видимому, подразумевает, что может иметь значение использование нескольких /s в пути

Допускается несколько косых черт, и они эквивалентны одной косой черте. Из спецификации Single Unix (версия 3) , базовые определения §3.266 pathname : «Несколько последовательных слешей считаются одинаковыми как один слеш».

Есть одно исключение: если имя пути начинается ровно с двух слэшей, оно может обрабатываться по-разному (см .: базовые определения §4.11 разрешение пути ). Сам Linux не делает этого, хотя некоторые приложения могут, а другие системы Unix-ish (например, Cygwin).

Завершающий /конец в конце имени пути заставляет имя пути ссылаться на каталог. В ( POSIX 1003.1-2001 определения (Single v3 Unix) базовых разрешениях имен путей §4.11 , замыкающий /эквивалентен завершающий /.. POSIX 1003.1-2008 (Single Unix v4) базовые определения §4.12 отменяет требование , чтобы сделать его эквивалент /., для того , справиться с несуществующими каталогами (например mkdir foo/, должен работать, а mkdir foo/.не будет - см. обоснование изменения).

Для программ, которые действуют на элемент каталога, если fooэто символическая ссылка на каталог, передача foo/является способом заставить программу действовать на каталог вместо символической ссылки.

¹ _{Обратите внимание, что это относится только к разрешению имени пути, то есть при доступе к файлам. Манипуляции с именами файлов могут работать по-разному. Например basenameи dirnameигнорировать косые черты.}

ОС, похоже, тоже не заботится об этом, только что попробовав программу на C с прямым системным вызовом, чтобы открыть с // в пути.

Вы можете использовать библиотечную функцию python os.path.normpath, чтобы нормализовать ее, что избавляет вас от необходимости просматривать строку в поисках дополнений. Другие языки имеют аналогичные функции.

http://docs.python.org/library/os.path.html#os.path.normpath

На всех Unix-системах, которые я видел, он такой же, как один /, но стандарт Unix указывает, что

Имя пути, начинающееся с двух последовательных слешей, может интерпретироваться способом, определяемым реализацией, хотя более двух ведущих слешей следует обрабатывать как один слеш.

так что это может быть обработано специально, в зависимости от вашей системы. (В некоторых старых версиях Unix /для удаленного доступа к файловой системе использовалось двойное ведение, но могут быть и другие.)

Используйте os.path.joinв Python, и вы не получите несколько слешей. Создание имен файлов путем объединения строк считается плохим стилем Python.

Нет никакой разницы.

Несколько косых черт игнорируются (без эффекта), например:

ls -al //usr///////bin/sed

Конечно, вы можете нормализовать путь с возможными множественными / (косыми чертами), пропустив его через tr -s

NORMALIZED=$(echo "$UNHYGIENIC" | tr -s / /)

... а затем использовать $NORMALIZED

Однако это должно быть необходимо. Насколько я знаю, любое ядро ​​UNIX должно игнорировать параллельные разделители пути - или концептуально трактовать их как ... /./...