[Linux/Unix] rm -R *.bak

Hallo,

klein obstakel, ik probeer met rm -R *.bak een aantal bak bestanden in de subdirectory te verwijderen ( bak is een backup file die naast het originele bestand bestaat en mogen aan het einde van de dag weg voordat de backup gemaakt wordt. Ik dacht dan ook met de optie -R ( recursive ) ook in subdirectories te kijken en zodoende ook de bestanden daar te verwijderen maar dat lukt dus niet. Alleen de bestanden in de current directory worden verwijderd.

Op mijn mac ( ook Unix dus ) krijg ik precies hetzelfde resultaat als op de computer waar het op moet gebeuren. ( een SuSe distro met bash als shell )

Ik heb allerlei combinaties geprobeerd waaronder het commando ls, opties als -Rf etc etc. Ook op Google kom ik eigenlijk niet veel verder. Volgens mij moet ik echt wat simpels over het hoofd zien dat dit niet werkt.

probeer eens -r

#su
#rm -R -f *.bak

find . -type f -name "*.bak" -exec rm -vf '{}' \;

De opmerkingen hierboven geven wel weer aan dat veel mensen niet even nadenken over hoe *.bak geëxpand wordt door de shell. Dat is killing als je met recursieve rm operaties aan de gang gaat. Heel verstandig ook om dat even als superuser te gaan proberen. Denk even na zeg. Een recursieve operatie op *.bak zou alle bestanden die *.bak heten verwijderen, en ook alle directories die *.bak heten met hun volledige inhoud verwijderen (wat die inhoud ook moge zijn).

In mijn voorbeeld zou je eerst doen:

find . -type f -name "*.bak"

Dan zie je vanzelf alle bestanden zien. Als je hebt geverifieerd dat alles weg mag, voeg je de -exec en de rest toe. Als je dit soort dingen liever niet eerst even "test": veel plezier met het slopen van je Linux machine.

Cheatah wijzigde dit bericht 24-07-2008 23:22 (87%)

inderdaad had ik diverse probeersels even met ls geprobeerd in eerste instantie en natuurlijk niet als root. In dit geval had ik niet veel uitgemaakt als de directories eindigend op .bak ook weg zouden worden gegooid maar ik kan me voorstellen wat het doet :-)

ben even aan het testen, zo terug.

edit @cheatah, toppie werkt helemaal !! bedankt

edit2; maar waarom werkte rm -R *.bak dan niet ? ( ook al is het niet verstandig ). al dan niet met hoofdletter R/r of de optie -f ( force )

erikafoort wijzigde dit bericht 24-07-2008 23:45 (24%)

Ik ben het met cheetah eens overigens. Zelf nooit de fout gemaakt om te rm -rf'en, maar je speelt altijd wel met vuur. De find-methode is veiliger. (ooit wel eens een chown www-data -R gedaan, vanuit de root, dan kan je ook naar je tapes grijpen

het is rm -r(f). Het is dan wel weer chown -R, or een ander commando wat recursief gedaan moet worden. Bij twijfel: man rm

* zal nooit expanden naar iets met een slash erin. Het kan expanden naar maximaal één component uit een path. Een directory test.bak zal dus *.bak matchen, maar test/file.bak niet.

De -f flag heeft gevolgen voor wat er gedaan wordt met alle gematchte componenten. De directory test.bak zal dus verwijderd worden als de -r flag is geset. Alles wat in die directory staat wordt dus verwijderd, of dat nu .bak bestanden zijn of niet.

Ik heb ooit met een 'ff snel typen actie' per ongeluk een spatie gezet tussen de * en de .bak (of watever daar toen stond) en dan heb je bij rm -rf wel een probleem Gelukkig had ik daar geen rechten om ook echt goed te slopen.

Een echte rm -rf /* zorgt ervoor dat je systeem binnen een paar minuten dan ook echt helemaal niks meer doet

De find is een goeie oplossing, -R werkt niet. Deze zoekt naar dirs met een .bak extensie om die dan met inhoud te verwijderen. En dat is niet wat je wil.

Wilde een opmerking maken over de dubbele quotes, maar dat gaat wel goed. Gebruik zelf altijd liever enkele quotes maar dat is in dit geval niet nodig.

sparks wijzigde dit bericht 25-07-2008 16:17 (68%)

quote:

sparks schreef op vrijdag 25 juli 2008 @ 16:07:
Wilde een opmerking maken over de dubbele quotes, maar dat gaat wel goed. Gebruik zelf altijd liever enkele quotes maar dat is in dit geval niet nodig.

Nee hoor:

% ls
index.html  index.html.bak  style.css  style.css.bak
% echo "*.bak"
*.bak

edit:
Te laat, sparks

deadinspace wijzigde dit bericht 25-07-2008 17:02 (21%)

Find met xargs is naar mijn mening de mooiste oplossing omdat xargs een stuk sneller is dan -exec

find . -type f -name "*.bak" -print0 | xargs -0 rm -rf

quote:

Stacheldraht schreef op vrijdag 25 juli 2008 @ 16:58:
Find met xargs is naar mijn mening de mooiste oplossing omdat xargs een stuk sneller is dan -exec

find . -type f -name "*.bak" -print0 | xargs -0 rm -rf

Jammer dat je dan toch de fout maakt die -r flag daar te zetten De -type f is natuurlijk voldoende om dat af te vangen, maar toch...

Het bekende typ foutje. Het moet natuurlijk dit zijn:

find . -type f -name "*.bak" -print0 | xargs -0 rm -f

quote:

erikafoort schreef op donderdag 24 juli 2008 @ 23:38:
edit2; maar waarom werkte rm -R *.bak dan niet ? ( ook al is het niet verstandig ). al dan niet met hoofdletter R/r of de optie -f ( force )

Dat komt door filename completion. Als je een commando op geeft, doet de shell eerst nog wat dingetjes voordat ie het laat uitvoeren waaronder filename completion. Stel je hebt file1.bak en file2.bak in een dir staan. Als je dan het commando rm -R *.bak opgeeft, dan doet de shell de filename completion nog voordat hij de instructies aan het commando rm doorgeeft. De shell kijkt in de huidige dir, ziet de 2 .bak files staan en verandert het commando in "rm -R file1.bak file2.bak". Dit geeft ie door aan rm, en rm verwijdert alleen deze bestanden, en niet de *.bak files in de subdirs.

quote:

3.5.8 Filename Expansion
After word splitting, unless the -f option has been set (see section 4.3 The Set Builtin), Bash scans each word for the characters ‘*’, ‘?’, and ‘[’. If one of these characters appears, then the word is regarded as a pattern, and replaced with an alphabetically sorted list of file names matching the pattern.

Van http://www.network-theory...ef/FilenameExpansion.html

Oftewel: bash probeert slim te zijn door de *.bak op je commandline te vervangen door de filename van alle bestanden in de huidige directory die aan dit patroon voldoen.

offtopic:
Oeps, moet verder omlaag scrollen.

Rainmaker wijzigde dit bericht 28-07-2008 09:17 (3%)

quote:

Cheatah schreef op vrijdag 25 juli 2008 @ 18:40:
[...]

Jammer dat je dan toch de fout maakt die -r flag daar te zetten De -type f is natuurlijk voldoende om dat af te vangen, maar toch...

Maakt in dit geval niet uit omdat find -type f toch alleen files teruggeeft. Maar mensen moeten idd wel afleren om 'rm -rf' niet als het standaard commando te zien ipv gewoon 'rm'.

quote:

Rainmaker schreef op maandag 28 juli 2008 @ 09:16:
Oftewel: bash probeert slim te zijn door de *.bak op je commandline te vervangen door de filename van alle bestanden in de huidige directory die aan dit patroon voldoen.

Bash moet wel, want rm doet niets met wildcards. :-)
code:

peter@iris:~/tmp$ ls
blaat  blaat.bak  file1  file1.bak  file2  file2.bak
peter@iris:~/tmp$ rm -r \*.bak
rm: cannot remove `*.bak': No such file or directory

quote:

zomertje schreef op vrijdag 25 juli 2008 @ 09:01:
Een echte rm -rf /* zorgt ervoor dat je systeem binnen een paar minuten dan ook echt helemaal niks meer doet

hij stopt toch nadat rm is verwijdert?

Iets in deze stijl?
code:

for i in `ls | grep .bak`; do echo $i; rm -rf $i; done

quote:

Arioch schreef op maandag 28 juli 2008 @ 21:21:
Iets in deze stijl?
code:

for i in `ls | grep .bak`; do echo $i; rm -rf $i; done

You're fired. om meer redenen dan 1.
Doe even je best om aan te wijzen waar je zelf cruciale fouten maakt.

Zo moeilijk is het allemaal écht niet. Maar ga anderen nou niet slechte gewoonten aanleren. Ik zal er al één verklappen die niet zo voor de hand ligt:

$ echo `ls /bin/rm`
/bin/rm
$ alias ls='ls -F'
$ echo `ls /bin/rm`
/bin/rm*
/bin/rmdir*

Het gebruiken van ls binnen scripts kan behoorlijk gevaarlijk zijn!

Andere fouten zijn natuurlijk het niet escapen van $i, het gebruik van de -r flag als je alleen bestanden wilt verwijderen.

Cheatah wijzigde dit bericht 28-07-2008 21:38 (42%)

quote:

daft_dutch schreef op maandag 28 juli 2008 @ 20:52:
hij stopt toch nadat rm is verwijdert?

Nee hoor. Als rm eenmaal is gestart, dan dendert hij vrolijk verder. Probeer maar uit

quote:

daft_dutch schreef op maandag 28 juli 2008 @ 20:52:
[...]

hij stopt toch nadat rm is verwijdert?

Probeer maar De laatste keer dat ik 't (opzettelijk ) deed niet. De binary is memory mapped, en de file wordt pas echt verwijderd als het aantal open handles verlaagd is naar nul. Zolang rm aan het uitvoeren is, wordt het dus nog even niet verwijderd. Dito voor de so's die rm gebruikt.

quote:

daft_dutch schreef op maandag 28 juli 2008 @ 20:52:
[...]

hij stopt toch nadat rm is verwijdert?

U gaat niet door voor de koelkast.

Als je Firefox draait en je gooit de Firefox binary weg, dan stopt het programma er ook niet mee. Het programma wordt namelijk in het geheugen geladen. Dit is nodig omdat programma's alleen vanuit het geheugen kan draaien en niet van harde schijf.

Het programma wordt niet eens helemaal in het geheugen geladen, maar gemapped, en wanneer nodig worden de pages van disk gelezen. De reden dat het programma dan niet stopt is omdat de use count (oid, ben even de term kwijt) nog niet naar nul is en de kernel het bestand dus nog niet echt verwijdert. Het is wel al niet meer zichtbaar in directory listings ed.

Wat een ingewikkeld gedoe om een paar .bak bestandjes weg te gooien zeg