Jak Linux obsługuje wiele kolejnych separatorów ścieżek (plik / home //// nazwa użytkownika ///)?

Pracuję nad skryptem Pythona, który przekazuje lokalizacje plików do podprocesu SCP. W porządku, ale jestem w sytuacji, w której mogę skończyć konkatenację ścieżki z nazwą pliku, tak aby /na ścieżce było podwójne . Wiem, że bash nie ma znaczenia, jeśli masz wiele separatorów plików, ale zastanawiam się, jak dokładnie to naprawić. Czy to bash, który usuwa dodatkowe /s, czy naprawdę to nigdy nie ma znaczenia?

Pytam, ponieważ zaoszczędzi mi to kilka wierszy kodu, aby sprawdzić dodatkowe /s podczas konkatenacji. Wiem, że to nie jest wielka sprawa, ale jestem też ciekawa. Mam skrypt bash, który ma linię cd //usr(zamiast cd /usr), co sugeruje, że może istnieć znaczenie używania wielu /s na ścieżce

Dozwolonych jest wiele ukośników i są one równoważne jednemu ukośnikowi. Ze specyfikacją Single Unix (wersja 3) , definicje podstawowych §3.266 ścieżka „Wielokrotne ukośniki są uważane za tak samo jak jeden ukośnik”

Jest jeden wyjątek: jeśli nazwa ścieżki rozpoczyna się dokładnie dwoma ukośnikami, może być traktowana inaczej (patrz: definicje podstawowe §4.11 rozpoznawanie nazwy ścieżki ). Sam Linux tego nie robi, chociaż niektóre aplikacje mogą tak zrobić, a inny system unixowy (np. Cygwin).

Znak /końca na końcu ścieżki wymusza na ścieżce odniesienie do katalogu. W definicjach podstawowych ( POSIX 1003.1-2001 (Single Unix v3) §4.11 rozpoznawanie nazw ścieżek , trailing /jest równoważny trailingowi /.. POSIX 1003.1-2008 (Single Unix v4) definicje podstawowe §4.12 usuwa wymóg, aby był równoważny /., w celu radzić sobie z nieistniejącymi katalogami (np. mkdir foo/jest wymagany do pracy, podczas gdy mkdir foo/.nie - patrz uzasadnienie zmiany).

W przypadku programów, które działają na wpisie katalogu, jeśli foojest dowiązaniem symbolicznym do katalogu, wówczas przekazanie foo/jest sposobem, aby program działał na katalogu zamiast dowiązania symbolicznego.

¹ _{Pamiętaj, że dotyczy to tylko rozpoznawania nazw ścieżek, tj. Podczas uzyskiwania dostępu do plików. Manipulacje nazwami plików mogą działać inaczej. Na przykład basenamei dirnameignoruj ​​końcowe ukośniki.}

Wygląda na to, że system operacyjny też się tym nie przejmuje, ponieważ właśnie wypróbował program C z bezpośrednim wywołaniem syscall, aby otworzyć go // na ścieżce.

Możesz jednak użyć funkcji biblioteki python os.path.normpath, aby go znormalizować, co oszczędza ci konieczności skanowania ciągu w poszukiwaniu dodatków. Inne języki mają podobne funkcje.

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

Na wszystkich systemach Unix, które widziałem, jest taki sam jak jeden /, ale standard Unix to określa

Ścieżka rozpoczynająca się od dwóch kolejnych ukośników może być interpretowana w sposób zdefiniowany w implementacji, chociaż więcej niż dwa początkowe ukośniki należy traktować jako pojedynczy ukośnik.

więc może być obsługiwany specjalnie, w zależności od systemu. (Niektóre starsze wersje Uniksa używały podwójnego wiodącego /dostępu do zdalnego systemu plików, a niektóre nadal mogą to robić).

Użyj os.path.joinw Pythonie, a nie dostaniesz wielu ukośników. Samo budowanie nazw plików przez łączenie łańcuchów jest uważane za kiepski styl Pythona.

Nie ma różnicy.

Wiele ukośników jest ignorowanych (bez efektu), np .:

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

Oczywiście możesz znormalizować ścieżkę z możliwą wielokrotnością / (ukośników) w niej, przechodząc przez nią tr -s

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

... a następnie użyj $NORMALIZED

Jednak powinno to być konieczne. O ile wiem, każde poprawnie jądro UNIX powinno zignorować równoczesne separatory ścieżek --- lub koncepcyjnie traktować je jako /./...