it-swarm.it

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

Sto lavorando a uno script python che passa le posizioni dei file a un sottoprocesso scp. Va bene, ma mi trovo in una situazione in cui potrei finire per concatenare un percorso con un nome file tale che c'è 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 in più /s o davvero non importa mai?

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

117
Falmarri

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

Esiste un'eccezione: se un percorso inizia con due caratteri successivi, il primo componente che segue i caratteri iniziali può essere interpretato in modo definito dall'implementazione. (rif: definizioni base §4.13 risoluzione percorso ). Linux stesso non lo fa, anche se alcune applicazioni potrebbero, e altri sistemi unix-ish (ad esempio Cygwin).

A trailing / alla fine di un nome percorso forza il nome percorso a fare riferimento a una directory. Nelle definizioni di base ( POSIX 1003.1-2001 (Single Unix v4) §4.11 risoluzione percorso , un trailing / equivale a un trascinamento /.. POSIX 1003.1-2008 (Single Unix v4) definizioni di base §4.1 rimuove il requisito per renderlo equivalente a /., per far fronte a directory inesistenti (ad esempio mkdir foo/ è necessario per funzionare, mentre mkdir foo/. not - vedi razionale per la modifica).

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

¹ Si noti 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. Ad esempio basename e dirname ignora le barre finali.

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 python libreria os.path.normpath per normalizzarlo, tuttavia, 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

17
Ivatar

Su tutti i sistemi Unix che ho visto è lo stesso di un singolo /, ma 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 alcuni.)

9
Fred Foo

Uso os.path.join in Python e non otterrai più barre. Costruire i nomi dei file concatenando le stringhe è considerato scarso Python.

7
Neil Mayhew

Non c'è differenza.

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

ls -al //usr///////bin/sed
3
ChristopheD

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

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

... e poi usa $NORMALIZED

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

0
Jim Dennis