Dlaczego rekurencja nie idzie w górę z rm?

Zastanawiam się ogólnie nad kierunkiem rekurencji, a konkretnie rm.

rekurencja rm działa tylko w dół, prawda?

Uruchamianie: sudo rm -R *.QTFSusunie wszystkie pliki * .QTFS z bieżącego katalogu i jego dzieci, prawda?

bieżący katalog wyświetlany przez ls -lhazawiera także .i ..linki z powodu braku lepszego słowa, więc dlaczego rekurencja nie podąża za nimi w drzewie katalogów? Czy istnieje granica sztuczna na rm aplikacji, albo .i ..nie są prawdziwe rzeczy?

recursive

Ponieważ korzeń i szaleństwo, w ten sposób leży ...

— jasonwryan

Powiązane: Czy „rm. *” Kiedykolwiek usuwa katalog nadrzędny?

— Stéphane Chazelas

Cóż, dla ciekawej anegdoty ... Uruchomiłem rm-rf w niektórych niewinnie wyglądających podkatalogach w jednym punkcie tylko po to, aby z przerażeniem stwierdzić, że użytkownik na stałe powiązał tam rzeczy z bardzo ważnym strumieniem, który następnie zaczął jeść. Tak, miałem bieżące kopie zapasowe i żadne dane nie zostały utracone, ale niech to będzie przestroga ... :-)

— Brian Knoblauch

@BrianKnoblauch, jaką szkodę można zrobić, usuwając twardy link? Nie zrozumiałem sensu twojej historii ...

— Alexey

@Alexey Chodzi o to, że sam twardy link nie został usunięty. Wrócił do twardego linku, który był połączony z wyższym punktem w systemie plików, więc zaczął jeść dane wszystkich ...

— Brian Knoblauch,

Odpowiedzi:

rm rekurencja działa tylko w dół, prawda?

rm -r x yusunie xi ywszystko w nich (jeśli są to katalogi), ale nie ich rodzice ani nic poza nimi.

Uruchamianie: sudo rm -R *.QTFSusunie wszystkie pliki * .QTFS z bieżącego katalogu i jego dzieci, prawda?

Nie. Spowoduje to usunięcie wszystkich nazwanych plików *.QTFS, wszystkich plików rekurencyjnie w wywoływanych katalogach*.QTFS i samych tych katalogów. Jeśli chcesz inne zachowanie związane z usuwaniem, użyj find -delete.

bieżący katalog wyświetlany przez ls -lhazawiera także .i ..linki z powodu braku lepszego słowa, więc dlaczego rekurencja nie podąża za nimi w drzewie katalogów? Czy istnieje granica sztuczna na rm aplikacji, albo .i ..nie są prawdziwe rzeczy?

To sztuczny limit rm.

Nie jest to jednak wcale takie sztuczne - to jedyny sposób, w jaki mógłby kiedykolwiek działać. Jeśli rmpodążą za ..linkami nadrzędnymi , każdy rm -rusunie każdy plik w systemie, podążając za wszystkimi ..linkami z powrotem do /. rmwidzi wpisy ..i .w każdym katalogu, gdy wyświetla zawartość, i jawnie je ignoruje z tego powodu.

W rzeczywistości możesz to wypróbować. Uruchom, rm -r .a większość rmimplementacji odmówi działania, jawnie zgłaszając błąd:

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

(ta wiadomość pochodzi z GNUrm ; inne są podobne). Kiedy napotyka te wpisy niejawnie, a nie jako wyraźne argumenty, po prostu je ignoruje i kontynuuje. Takie zachowanie jest wymagane przez POSIX . W GNU rmi wielu BSD jest on dostarczany automatycznie przez fts_readrodzinę funkcji przechodzących przez hierarchię.

lub .i ..czy nie są prawdziwe?

.i ogólnie.. są to prawdziwe wpisy katalogu, chociaż jest to specyficzne dla systemu plików. Prawie zawsze będą prezentowane tak, jakby były prawdziwymi wpisami do całego kodu użytkownika, niezależnie od tego. Wiele programów (nie tylko ) specjalizuje się w ich zachowaniu w celu wychwycenia lub uniknięcia niekontrolowanej lub niepożądanej rekurencji.rm

— Michael Homer
źródło

Dla każdego, kto szuka dowodu (lub po prostu zainteresowany), spójrz, jak jest to zaimplementowane w jądrach GNU .

— Chris Hayes

@ChrisHayes Odpowiednik linku gitweb znajduje się w odpowiedzi. Rzeczywisty przypadek rekurencyjny jest w fts_readimplementacji, ten dotyczy tylko argumentów wiersza poleceń.

— Michael Homer

@MichaelHomer O wow, więc tak jest. Ten kolor łącza nie wyróżnia się na tym schemacie SE. Mój błąd.

— Chris Hayes

Ta odpowiedź jest poprawna, ale także trochę nieprecyzyjna. rmnawet nie widzi, *.QTFSponieważ jest rozszerzony globalnie do nazw plików przez bash przed wywołaniem pliku binarnego rm. Odpowiedź @ tobyink zauważa, że.

— Daenyth,

Mówiąc prościej, uważa się , że te .i ..zachowanie w szczególnych przypadkach są przyczyną istnienia

— plików dotfiles

Oprócz tego, co napisał Michael Homer, istnieje jeszcze jeden czynnik, który utrudnia przypadkowe ponowne przejście do katalogu nadrzędnego.

Przejdź do katalogu domowego i wpisz coś takiego:

echo *s*

Zobaczysz, że pokazuje listę plików i katalogów zawierających literę „s”. Jednak żadne pliki zaczynające się od wiodącej kropki nie są wyświetlane. Aby je pokazać, możesz użyć:

echo .*s*

Wynika to z faktu, że powłoka odmawia rozszerzenia, *aby objąć wiodącą kropkę. To znaczy że:

rm -fr *

Nie powróci do ...

— Tobyink
źródło