In che modo Linux gestisce più separatori di percorsi consecutivi (/ home //// nome utente /// file)?

Sto lavorando a uno script Python che passa i percorsi dei file a un sottoprocesso scp. Va tutto bene, ma mi trovo in una situazione in cui potrei finire per concatenare un percorso con un nome file tale che ci sia un doppio " /nel percorso. So che a bash non importa se hai più separatori di file, ma mi chiedo come sia corretto. È bash che spoglia di più /o davvero non importa mai?

Chiedo perché mi salverà diverse righe di codice per verificare se sono presenti ulteriori messaggi /concatenati. So che non è un grosso problema, ma sono anche curioso. Ho uno script bash che ha la linea cd //usr(anziché cd /usr), il che sembra implicare che potrebbe esserci un significato nell'uso di più /s in un percorso

Sono consentite più barre e equivalgono a una singola barra. Dalla specifica Single Unix (versione 3) , definizioni di base §3.266 nome percorso : "Molte barre successive sono considerate uguali a una barra".

C'è un'eccezione: se un percorso inizia esattamente con due barre, può essere trattato in modo diverso (rif: definizioni base §4.11 risoluzione percorso ). Linux stesso non lo fa, anche se alcune applicazioni potrebbero farlo e altri sistemi unix-ish (ad esempio Cygwin).

Un finale /alla fine di un percorso obbliga il percorso a fare riferimento a una directory. Nelle definizioni di base ( POSIX 1003.1-2001 (Single Unix v3) §4.11 risoluzione percorso , un trailing /equivale a un trailing /.. Le definizioni di base POSIX 1003.1-2008 (Single Unix v4) §4.12 rimuovono il requisito per renderlo equivalente /., al fine per far fronte a directory inesistenti (ad esempio, mkdir foo/è necessario per funzionare, mentre mkdir foo/.non dovrebbe - vedere la logica del cambiamento).

Per i programmi che agiscono su una voce della directory, se fooè un collegamento simbolico a una directory, il passaggio foo/è un modo per far sì che il programma agisca sulla directory anziché sul collegamento simbolico.

¹ _{Notare che ciò vale solo per la risoluzione del nome percorso, ovvero quando si accede ai file. Le manipolazioni del nome file potrebbero funzionare in modo diverso. Per esempio basenamee dirnameignorare slash.}

Anche il sistema operativo non sembra preoccuparsene, avendo appena provato un programma C con una scala di sistema diretta da aprire con un // nel percorso.

Puoi usare la funzione di libreria python os.path.normpath per normalizzarlo però, il che ti evita di scansionare la stringa in cerca di extra. Altre lingue hanno funzioni simili.

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

Su tutti i sistemi Unix che ho visto è lo stesso di un singolo /, ma lo standard Unix lo specifica

Un nome di percorso che inizia con due barre successive può essere interpretato in modo definito dall'implementazione, anche se più di due barre iniziali devono essere trattate come una barra singola.

quindi può essere gestito appositamente, a seconda del sistema. (Alcune versioni precedenti di Unix utilizzavano un doppio vantaggio /per l'accesso al filesystem remoto e potrebbero essercene ancora alcune.)

Usa os.path.joinin Python e non otterrai più barre. Costruire i nomi dei file concatenando le stringhe è considerato un povero stile Python.

Non c'è differenza.

Le barre multiple vengono ignorate (senza effetto), ad esempio:

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

Ovviamente puoi normalizzare un percorso con possibili multipli / (barre) passandoci attraverso tr -s

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

... e poi usa $NORMALIZED

Tuttavia, dovrebbe essere necessario. Per quanto ne so, qualsiasi kernel UNIX dovrebbe ignorare i separatori di percorsi simultanei --- o trattarli concettualmente come ... /./...