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

<p>я работаю над сценарием python), который передает местоположения файлов в подпроцесс scp. все нормально, но я нахожусь в ситуации, когда я могу конкатенировать путь с именем файла, так что есть двойной '<code>/</code> в пути. я знаю, что bash не волнует, если у вас есть несколько разделителей файлов, но мне интересно, как именно это исправить. это bash, который лишает лишних <code>/</code>s или это действительно не имеет значения когда-либо?</p><p>я спрашиваю, потому что это сэкономит мне несколько строк кода, чтобы проверить дополнительные <code>/</code>s при объединении. я знаю, что это не имеет большого значения, но мне тоже любопытно. у меня есть сценарий bash, который имеет строку <code>cd //usr</code> (вместо <code>cd /usr</code>), что, по-видимому, предполагает использование нескольких <code>/</code>s в пути</p>

<p>допускается несколько косых черт, которые эквивалентны одной косой черте. из <a href="https://pubs.opengroup.org/onlinepubs/9699919799">спецификация single unix (версия 4)</a> , <a href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/v1\_chap03.html#tag\_03\_271">базовые определения §3.271 pathname</a> : "несколько последовательных слешей считаются одинаковыми как один слеш".</p><p>есть одно исключение: если имя пути начинается с двух последовательных символов, первый компонент, следующий за начальными символами, может интерпретироваться в зависимости от реализации. (ссылка: <a href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/v1\_chap04.html#tag\_04\_13">базовые определения §4.13 разрешение пути</a> ). сам linux не делает этого, хотя некоторые приложения могут, а другие системы unix-ish (например, cygwin).</p><p>трейлинг <code>/</code> в конце имени пути заставляет имя пути ссылаться на каталог. в ( <a href="http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd\_chap04.html#tag\_04\_11">базовые определения posix 1003.1-2001 (single unix v4) §4.11 разрешение пути</a> , завершающий <code>/</code> эквивалентно завершающему <code>/.</code>. <a href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/v1\_chap04.html#tag\_04\_13">базовые определения posix 1003.1-2008 (single unix v4) §4.1</a> устраняет требование сделать его эквивалентным <code>/.</code>, чтобы справиться с несуществующими каталогами (например, <code>mkdir foo/</code> требуется для работы, тогда как <code>mkdir foo/.</code> не будет - см. <a href="http://pubs.opengroup.org/onlinepubs/9699919799/xrat/v4\_xbd\_chap04.html#tag\_21\_04\_13">обоснование</a> изменения).</p><p>для программ, которые работают с записью каталога, если <code>foo</code> является символической ссылкой на каталог, то передача <code>foo/</code> - это способ заставить программу действовать в каталоге вместо символической ссылки.</p><p>¹ <sub>обратите внимание, что это применимо только к разрешению пути, то есть при доступе к файлам. манипуляции с именами файлов могут работать по-разному. например <a href="http://www.opengroup.org/onlinepubs/009695399/functions/basename.html"><code>basename</code></a> и <a href="http://www.opengroup.org/onlinepubs/009695399/functions/dirname.html"><code>dirname</code></a> игнорировать завершающие косые черты.</sub></p>

<p>похоже, операционная система тоже не заботится об этом, только что попробовав программу на c с прямым системным вызовом, открывающуюся с // в пути.</p><p>вы можете использовать python os.path.normpath, чтобы нормализовать ее, что избавляет вас от необходимости сканировать строку в поисках дополнительных функций. другие языки имеют аналогичные функции.</p><p> <a href="http://docs.python.org/library/os.path.html#os.path.normpath">http://docs.python.org/library/os.path.html#os.path.normpath</a> </p>

<p>на всех unix-системах, которые я видел, он такой же, как одиночный <code>/</code>, но <a href="http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd\_chap04.html#tag\_04\_11">стандарт unix</a> указывает, что</p><blockquote> <p>имя пути, начинающееся с двух последовательных слешей, может интерпретироваться способом, определяемым реализацией, хотя более двух ведущих слешей должны обрабатываться как один слеш.</p> </blockquote><p>так что это может быть обработано специально, в зависимости от вашей системы. (некоторые старые версии unix использовали двойное ведение <code>/</code> для удаленного доступа к файловой системе, и некоторые из них могут быть.)</p>

<p>используйте <a href="https://docs.python.org/2/library/os.path.html#os.path.join"><code>os.path.join</code></a> in python и вы не получите несколько слэшей. создание имен файлов самостоятельно путем объединения строк считается плохим python.</p>

<p>нет никакой разницы.</p><p>несколько косых черт игнорируются (без эффекта), например:</p><pre><code>ls -al //usr///////bin/sed </code></pre>

<p>конечно, вы можете нормализовать путь с несколькими возможными/(косыми чертами), пропустив его через <code>tr -s</code></p><pre><code>normalized=$(echo "$unhygienic" | tr -s / /) </code></pre><p>... а затем используйте <code>$normalized</code></p><p>однако это должно быть необходимо. насколько я знаю, любое ядро unix должно игнорировать параллельные разделители пути - или концептуально обрабатывать их как ...<code>/./</code>...</p>