Jak Linux zpracovává více po sobě jdoucích oddělovačů cest (/ home //// username /// file)?
Pracuji na skriptu python), který předává umístění souboru do podprocesu scp. To je v pořádku, ale jsem v situaci, kdy mohu skončit zřetězením cesty s názvem souboru, že v cestě je dvojitá '/. Vím, že bashovi nezáleží, pokud máte více oddělovačů souborů, ale zajímalo by mě, jak přesně je to napraveno. Je to bash, který stripuje navíc / s nebo na tom vůbec nezáleží?
Ptám se, protože mi to ušetří několik řádků kódu, abych zkontroloval extra / s při zřetězení. Vím, že to není velký problém, ale jsem také zvědavý. Mám bash skript, který má řádek cd //usr (namísto cd /usr), což zřejmě naznačuje, že by mohl být význam použití více / s v cestě
Povoleno je více lomítek a jsou ekvivalentní jedné lomce. Z Specifikace Single Unix (verze 4) , základní definice §3.271 pathname : „Více po sobě následujících lomítek je považováno za stejné jako jedno lomítko.“
Existuje jedna výjimka: Pokud cesta začíná dvěma po sobě jdoucími znaky, může být první komponenta následující za úvodními znaky interpretována implementačně definovaným způsobem. (viz: základní definice §4.13 rozlišení názvu cesty ). Samotný Linux to nedělá, ačkoli některé aplikace mohou, a jiný unix-ish systém (např. Cygwin).
Koncové / na konci cesty vynutí cestu k odkazu na adresář. V ( POSIX 1003.1-2001 (Single Unix v4) základní definice §4.11 rozlišení názvu cesty , koncové / je ekvivalentní koncové /.. POSIX 1003.1-2008 (Single Unix v4) základní definice §4.1 odstraňuje požadavek, aby byl ekvivalentní /., abychom se vypořádali s neexistujícími adresáři (např. mkdir foo/ musí pracovat, zatímco mkdir foo/. by ne - viz zdůvodnění pro změnu).
U programů, které působí na položku adresáře, je-li foo symbolickým odkazem na adresář, pak předání foo/ je způsob, jak přimět program, aby působil v adresáři místo symbolického odkazu.
¹ Toto platí pouze pro rozlišení názvu cesty, tj. Při přístupu k souborům. Manipulace s názvem souboru mohou fungovat odlišně. Například basename a dirname ignoruje koncové lomítka.
Zdá se, že OS se o to nestará ani poté, co právě vyzkoušel program C s přímým syscallem, který se otevřel s // v cestě.
Můžete jej však použít k normalizaci funkce python knihovna funkce os.path.normpath), což vám ušetří skenování řetězce hledáním doplňků. Jiné jazyky mají podobné funkce.
http://docs.python.org/library/os.path.html#os.path.normpath
Na všech unixových systémech, které jsem viděl, je to stejné jako jediný /, ale standard Unix to specifikuje
Cesta, která začíná dvěma po sobě jdoucími lomítky, může být interpretována implementačně definovaným způsobem, ačkoli s více než dvěma předními lomítky se bude zacházet jako s jediným lomítkem.
takže to může být zpracováno speciálně v závislosti na vašem systému. (Některé starší unixové verze používaly dvojité vedoucí / pro vzdálený přístup k souborovým systémům a některé mohou stále existovat.)
Použijte os.path.join in Python a nedostanete více lomítek. Vytváření názvů souborů zřetězením řetězců je považováno za špatné Python styl).
Není žádný rozdíl.
Více lomítek bude ignorováno (bez účinku), např .:
ls -al //usr///////bin/sed
Samozřejmě můžete normalizovat cestu s možným vícenásobným/(lomítkem) v ní průchodem tr -s
NORMALIZED=$(echo "$UNHYGIENIC" | tr -s / /)
... a poté použijte $NORMALIZED
Mělo by to však být nutné. Stejně jako vím, jakékoli řádné jádro UNIX by mělo ignorovat souběžné oddělovače cest --- nebo je koncepčně považovat za ..././...