Як Linux обробляє декілька послідовних роздільників шляхів (/ home //// ім'я користувача /// файл)?

Я працюю над сценарієм python, який передає місця розташування файлів у підпроцес scp. Це все добре, але я знаходжусь у ситуації, коли я можу в кінцевому рахунку об'єднати шлях з назвою файлу таким чином, що /на шляху є подвійний ' . Я знаю, що bash не має значення, якщо у вас є кілька роздільників файлів, але мені цікаво, як саме це виправлено. Це башти, які знімають зайві /або це ніколи не має значення?

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

Допускається декілька косої риски і рівнозначна одній косій косій рисі. З специфікації Single Unix (версія 3) , базове визначення §3.266 ім'я шляху : "Кілька послідовних косої риси вважаються такими ж, як одна коса риса".

Є один виняток: якщо ім'я шляху починається рівно з двох нахилів, воно може трактуватися по-різному (посилання: базові визначення § 4.11 роздільна здатність назви шляху ). Сам Linux цього не робить, хоча деякі програми та інші системи Unix-ish роблять (наприклад, Cygwin).

Трейлінг /в кінці імені шляху змушує шлях посилатися на каталог. У базових визначеннях ( POSIX 1003.1-2001 (Single Unix v3)) §4.11 роздільна здатність імені траєкторії , трейлінг /є еквівалентом трейлінгу /.. Основні визначення POSIX 1003.1-2008 (Single Unix v4) §4.12 знімає вимогу зробити його еквівалентним для того /., щоб щоб впоратися з неіснуючими каталогами (наприклад mkdir foo/, потрібна робота, тоді як mkdir foo/.не буде - див. обґрунтування змін).

Для програм, які діють на запис в каталозі, якщо fooце символічне посилання на каталог, то передача foo/- це спосіб зробити програмний акт в каталозі замість символічного посилання.

¹ _{Зауважте, що це стосується лише дозволу імені шляху, тобто для доступу до файлів. Маніпуляції з іменем файлів можуть працювати по-різному. Так , наприклад , basenameі dirnameігнорувати задні косу риску.}

Здається, ОС також не переймається цим, щойно спробувавши програму C з прямим syscall, щоб відкрити // зі шляху.

Ви можете використовувати функцію бібліотеки 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 повинно ігнорувати паралельні роздільники шляху або концептуально трактувати їх як ... /./...