Jaki jest powód współistnienia rmdir (1) i rm (1)?


Odpowiedzi:


27

Głównym powodem jest prawdopodobnie historyczny. Powrót do dawnych, dawnych czasach, tam nie byli rmdir(2)i mkdir(2)wywołania systemowe (mówimy o 7th Edition UNIX ™ tutaj), i rmdir(1)był (z konieczności) program korzeń SUID że użył unlink(2)wywołania systemowego usunięcia katalogów.

Instrukcje UNIX 7. edycji są dostępne online pod adresem http://cm.bell-labs.com/7thEdMan (ostatnio sprawdzone 23.04.2017); Są one również dostępne na stronie http://plan9.bell-labs.com/7thEdMan (ostatnio sprawdzono 23.04.2017). Wydaje się również, że istnieje co najmniej jedno alternatywne źródło online - http://wolfram.schneider.org/bsd/7thEdManVol2/ - dla artykułów w Tomie 2, z linkiem do strony FreeBSD dla poleceń i wywołań systemowych w Tomie 1 .

rmPoleceń (regularnym programem non-SUID) powołuje się na rmdir(1)komendę w celu usunięcia pustych katalogów. Nie mógł tego zrobić sam; wymagało to uprawnień roota. Tak więc rmdir(1)polecenie (patrz tutaj jego kod źródłowy w Uniksie V7) istniało w celu usunięcia pustych katalogów, a samo rmpolecenie nie usunęło pustych katalogów.

Aby użyć rmdo usunięcia katalogów, musisz podać -ropcję.

Istnieje również argument symetrii. Potrzebujesz polecenia, mkdir(1)aby utworzyć katalogi; wydaje się rozsądne mieć polecenie rmdir(1)cofnięcia tego, co mkdir(1)zrobiono. Dodatkowo są one (obecnie) prostymi ćwiczeniami wywołań systemowych rmdir(2)i mkdir(2)- tak, w 7. edycji UNIX, mkdir(1)był także programem głównym SUID, wykorzystującym mknod(2)wywołanie do utworzenia węzła katalogu i link(2)wywołanie do utworzenia pozycji .i ..wpisów w katalogu .


Aha! to wszystko ma sens, świetnie!

2
Ładny. Właśnie sprawdziłem kopię 3BSD, którą tu mam, i nie ma tam dokumentacji dla syscall rmdir, a rmdir (1) jest nadal implementowany za pomocą unlink.
Andy Ross

4
Jednym z głównych minusów systemu mknod + link i unlink było to, że utworzenie katalogu nie było operacją atomową, więc można skończyć z częściowo kompletnym katalogiem. Opracowano wiele programów sprawdzających systemy plików pod kątem powstałych niespójności; fsck(1)to ten, który przeżył.
Jonathan Leffler

@Jonathan, przywołując wspomnienia z Xenixa. Fuj! Tak, mogą się zdarzyć naprawdę złe rzeczy.
Fiasco Labs

6

„rm” nie działa na katalogach. Musisz użyć rmdir lub określić przełącznik -r w celu usunięcia rekurencyjnego. Powodem jest historyczny: unlinka rmdirto oddzielne wywołania systemowe i zostały od pierwszych dni Unix.


4
Pozytywnym efektem ubocznym jest to, że nieznacznie rzadziej przypadkowo usuwasz katalog, gdy zamierzasz usunąć tylko plik.

Dziękuję Ci. Zauważyłem, że „rm -r” i „rmdir” mają taką samą liczbę naciśnięć klawiszy. Czy rmdir istnieje wyłącznie z powodów historycznych (.. jest kompatybilny ze starymi programami uniksowymi)?

2
W rzeczywistości, w początkowych czasach Uniksa, ani rmdir(2)nie mkdir(2)istniało jako wywołanie systemowe; użytkownik rootmoże użyć mknod(2)wywołania, aby utworzyć węzeł katalogu i link(2)wywołania, aby utworzyć wpisy .i ..w katalogu; i rootmoże użyć unlink(2)połączenia, aby usunąć wpisy z książki telefonicznej.
Jonathan Leffler

3

Również rmdir usuwa tylko puste katalogi. Jeśli chcesz mieć pewność, że nie usuniesz żadnych dodatkowych plików w katalogu, rmdirjest to bezpieczniejsze niż rm -r(z wyjątkiem przypadku aliasu rm tak, że zawsze musisz potwierdzić to, co usuwasz, np. alias rm='rm -i'W ~ / .bashrc lub cokolwiek, którego używasz ).


1

Również rmdirułatwia usuwanie pustych katalogów z globbing (wieloznacznych) wyrażenia. Na przykład, aby usunąć wszystkie puste katalogi /tmpbez dotykania plików lub katalogów z zawartością:

cd /tmp ; rmdir *

Rozważ użycie rmdir /tmp/*. Jeśli /tmpkatalog jest naprawdę duży, może zabraknąć miejsca na argumenty nieco ze względu na dodatkowe pięć znaków na nazwę, ale nie wymaga cdprzenoszenia się w hierarchii katalogów. Warto również rozważyć rmdir /tmp/* 2>/dev/nullunikanie komunikatów o błędach (zwykle będzie ich dużo i prawie wszystkie z nich nie będą miały znaczenia dla tego zadania).
Jonathan Leffler,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.