Perché la ricorsione non aumenta con rm?

Mi chiedo quale sia la direzione della ricorsione in generale e rm in particolare.

rm ricorsione funziona solo verso il basso, giusto?

In esecuzione: sudo rm -R *.QTFSeliminerà tutti i file * .QTFS nella directory corrente e i relativi figli, giusto?

la directory corrente come visualizzata da ls -lhacontiene anche .e ..collegamenti per la mancanza di una parola migliore, quindi perché la ricorsione non li segue verso l'alto nella struttura delle directory? C'è un limite artificiale sulla rm app, o .e ..non sono cose reali?

recursive

Perché radice e follia in quel modo risiede ...

— Jasonwryan,

Correlati: 'rm. *' Elimina mai la directory principale?

— Stéphane Chazelas,

Bene, per un aneddoto interessante ... Ho eseguito rm -rf su alcune sottodirectory dall'aspetto innocente ad un certo punto solo per scoprire con mio orrore che un utente aveva cose molto collegate lì dentro a un monte molto importante, che poi ha continuato a mangiare. Sì, avevo i backup correnti e nessun dato è andato perso, ma lascia che sia una storia di ammonimento ... :-)

— Brian Knoblauch

@BrianKnoblauch, quale danno si potrebbe fare rimuovendo un collegamento reale? Non ho capito il punto della tua storia ...

— Alexey,

@Alexey Il punto è che il collegamento reale non è stato rimosso. Ricorse nella directory hard link, che era collegata a un punto più alto del filesystem, quindi iniziò a mangiare i dati di tutti ...

— Brian Knoblauch

Risposte:

rm la ricorsione funziona solo verso il basso, giusto?

rm -r x ycancellerà xe ytutto ciò che contiene (se sono directory), ma non i loro genitori o qualcosa al di fuori di essi.

In esecuzione: sudo rm -R *.QTFSeliminerà tutti i file * .QTFS nella directory corrente e i relativi figli, giusto?

No. Eliminerà tutti i file nominati *.QTFS, tutti i file ricorsivamente all'interno delle directory chiamate *.QTFSe quelle stesse directory. Se si desidera quell'altro comportamento di eliminazione, utilizzare find -delete.

la directory corrente come visualizzata da ls -lhacontiene anche .e ..collegamenti per la mancanza di una parola migliore, quindi perché la ricorsione non li segue verso l'alto nella struttura delle directory? C'è un limite artificiale sulla rm app, o .e ..non sono cose reali?

È un limite artificiale di rm.

In realtà non è poi così artificiale - è l'unico modo in cui potrebbe mai funzionare. Se rmseguissero i ..collegamenti principali , ognuno rm -rrimuoverà tutti i file sul sistema, seguendo tutti i ..collegamenti fino al ritorno /. rmvede le voci ..e .in ciascuna directory quando elenca il contenuto e le ignora esplicitamente per quel motivo.

Puoi provarlo tu stesso, in effetti. Esegui rm -r .e la maggior parte delle rmimplementazioni rifiuteranno di agire, segnalando esplicitamente un errore:

$ rm -r .
rm: refusing to remove ‘.’ or ‘..’ directory: skipping ‘.’

(quel messaggio proviene da GNUrm ; altri sono simili). Quando incontra queste voci implicitamente, piuttosto che come argomenti espliciti, le ignora e continua. Tale comportamento è richiesto da POSIX . In GNU rme in molti BSD, viene fornito automaticamente dalla fts_readfamiglia di funzioni di gerarchia-attraversamento.

o .e ..non sono cose reali?

.e ..sono in genere voci di directory reali, sebbene siano specifiche del file system. Saranno quasi sempre presentati come se fossero voci reali per tutto il codice utente, indipendentemente. Molti software (e non solo rm) hanno un caso particolare il loro comportamento al fine di catturare o impedire la fuga o la ricorsione indesiderata.

— Michael Homer
fonte

Per chiunque sia alla ricerca di prove (o semplicemente interessato), dai un'occhiata a come questo è implementato nei coreutils GNU .

— Chris Hayes,

@ChrisHayes Il link gitweb equivalente è nella risposta. Il caso reale ricorsivo è fts_readnell'implementazione, tuttavia, quello è solo per argomenti da riga di comando.

— Michael Homer,

@MichaelHomer Oh wow, così è. Quel colore di collegamento non spicca su questo schema SE. Errore mio.

— Chris Hayes,

Questa risposta è corretta ma anche un po 'imprecisa. rmnon vede nemmeno *.QTFSperché viene espanso a livello globale nei nomi dei file di bash prima che venga invocato il binario rm. La risposta di @ tobyink lo osserva.

— Daenyth,

Come sidenote, si dice che quelli .e il ..comportamento in casi speciali siano la causa dell'esistenza dei dotfile

— Margarciaisaia,

Oltre a ciò che ha scritto Michael Homer, c'è un altro fattore che rende difficile ricorrere accidentalmente nella directory padre.

Vai nella tua home directory e digita qualcosa del tipo:

echo *s*

Vedrai che mostra un elenco di file e directory contenenti la lettera "s". Tuttavia, non vengono visualizzati file che iniziano con un punto iniziale. Per mostrarli, puoi usare:

echo .*s*

Questo perché la shell rifiuta di espandersi *per comprendere un punto iniziale. Ciò significa che:

rm -fr *

Non ricorrere in ...

— tobyink
fonte