Qual è il motivo della coesistenza di rmdir (1) e rm (1)?


Risposte:


27

Il motivo principale è probabilmente storico. Ritorno ai vecchi, vecchi tempi, non ci sono stati rmdir(2)e mkdir(2)chiamate di sistema (stiamo discutendo 7th Edition UNIX ™ qui), e rmdir(1)fu (per necessità) un programma SUID root che ha utilizzato il unlink(2)chiamata di sistema per rimuovere le directory.

I manuali UNIX della 7a edizione sono disponibili online all'indirizzo http://cm.bell-labs.com/7thEdMan (ultimo controllo 23-04-2017); Sono disponibili anche su http://plan9.bell-labs.com/7thEdMan (ultimo controllo 23-04-2017). Sembra anche che ci sia almeno una fonte alternativa online - http://wolfram.schneider.org/bsd/7thEdManVol2/ - per gli articoli nel Volume 2, con un collegamento al sito FreeBSD per i comandi e le chiamate di sistema nel Volume 1 .

Il rmcomando (un normale programma non SUID) ha invocato il rmdir(1)comando per rimuovere le directory vuote. Non poteva farlo da solo; che richiedeva privilegi di root. Quindi, il rmdir(1)comando (vedi qui per il suo codice sorgente in Unix V7) esisteva per rimuovere le directory vuote e il rmcomando non rimuoveva le directory vuote.

Per utilizzare rmper rimuovere le directory, devi dare l' -ropzione.

C'è anche un argomento di simmetria. È necessario un comando mkdir(1)per creare directory; sembra ragionevole avere un comando rmdir(1)per annullare ciò che ha mkdir(1)fatto. Inoltre sono (in questi giorni) semplici esercitatori delle chiamate the rmdir(2)e di mkdir(2)sistema - sì, già nella 7a Edizione UNIX, mkdir(1)era anche un programma root SUID, usando la mknod(2)chiamata per creare un nodo di directory e la link(2)chiamata per creare le voci .e ..nella directory .


aha! tutto questo ha un senso, fantastico!

2
Bello. Ho appena controllato una copia di 3BSD che ho qui e non c'è nemmeno la documentazione per un syscall di rmdir e rmdir (1) è ancora implementato usando unlink.
Andy Ross,

4
Uno dei principali svantaggi del sistema mknod + link e unlink era che la creazione di una directory non era un'operazione atomica, quindi potresti finire con una directory parzialmente completa. Ci sono stati molti programmi ideati per controllare i file system per le incongruenze sorte; fsck(1)è quello che è sopravvissuto.
Jonathan Leffler,

@Jonathan, riportando ricordi di Xenix su quello. Che schifo! Sì, potrebbero davvero succedere cose brutte.
Fiasco Labs,

6

"rm" non funziona su directory. Devi usare rmdir o specificare l'opzione -r per una cancellazione ricorsiva. La ragione è storica: unlinke rmdirsono chiamate di sistema separati e sono stati fin dai primi giorni di Unix.


4
Un felice effetto collaterale è che hai meno probabilità di eliminare accidentalmente una directory quando intendi rimuovere solo un file.

Grazie. Ho notato che "rm -r" e "rmdir" hanno la stessa quantità di tasti premuti. Rmdir esiste solo per ragioni storiche (.. essendo compatibile con decenni di programmi Unix)?

2
In realtà, nei primi tempi di Unix, rmdir(2)mkdir(2)esisteva né come chiamata di sistema; l'utente rootpuò usare la mknod(2)chiamata per creare un nodo di directory e la link(2)chiamata per creare le voci .e ..nella directory; e rootpotrebbe usare la unlink(2)chiamata per rimuovere le voci della rubrica.
Jonathan Leffler,

3

Inoltre rmdir rimuove solo le directory vuote . Se vuoi assicurarti di non eliminare alcun file aggiuntivo in una directory, rmdirè più sicuro di rm -r(tranne se hai alm rm tale che devi sempre confermare ciò che elimini, cioè alias rm='rm -i'in ~ / .bashrc o qualunque cosa tu stia usando ).


1

Inoltre, rmdirsemplifica la rimozione di directory vuote con espressioni globbing (jolly). Ad esempio, per rimuovere tutte le directory vuote /tmpsenza toccare alcun file o directory con contenuti:

cd /tmp ; rmdir *

Prendi in considerazione l'utilizzo rmdir /tmp/*. Se la /tmpdirectory è davvero grande, questo potrebbe esaurire lo spazio per gli argomenti un po 'più veloce a causa dei cinque caratteri extra per nome, ma non richiede cddi spostarti nella gerarchia di directory. Vale anche la pena considerare rmdir /tmp/* 2>/dev/nulldi evitare di vedere i messaggi di errore (in genere ce ne saranno molti e quasi tutti saranno irrilevanti per tale compito a portata di mano).
Jonathan Leffler,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.