• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Dateien löschen mit rm

Escho

Escho

Advanced Hacker
Guten Morgen!

Mit rm lassen sich ja in einem Verzeichnes alle Dateien löschen:
Code: 
rm /verzeichnis/*
Ich möchte in diesem Verzeichnis nun aber alle Dateien löschen bis auf Dateien, die auf .mpg enden.

"man rm" bietet mir keine Option für das Ausschließen bestimmter Dateien vom Löschen an. Gibt es da einen anderen Befehl, der sowas kann?

Edgar
 
OP
Escho

Escho

Advanced Hacker
Damit geht's.
Ich hab gerade die Manualseiten von find und xargs durchgesehen und muß zugeben: Da wäre ich nie im Leben drauf gekommen.
Danke für den Tip.

Edgar
 
OP
Escho

Escho

Advanced Hacker
abgdf schrieb:
Vielleicht ist
Code: 
rm $(ls | grep -v ".mpg$")
etwas leichter zu verstehen ...
Zum Vergrößern anklicken....
Nicht unbedingt, da ich es bisher erfolgreich vermieden habe, mich mit grep herumzuschlagen. Also neu ist neu.:wink:
Macht aber nichts, denn ich weiß nun, daß es geht und wo ich ansetzen muß.

Edgar
 
OP
Escho

Escho

Advanced Hacker
So! Jetzt habt ihr mich neugierig gemacht. Jetzt werde ich doch mal nachlesen, was der Befehl von abgdf wirklich bewirkt.
Ausprobieren tue ich Löschbefehle sowieso erst, wenn ich sie auch in der Theorie verstanden habe.

Edgar
 
T

trommelpeter

Member
Bist du des Wahnsinn!

Code:

touch wichtig.txt
touch `echo -en "wichtig.txt\nwichtig.mpg"`
rm $(ls | grep -v ".mpg$")
Zum Vergrößern anklicken....

Kann den Denkfehler leider nicht erkennen. das $ markiert bei grep das der gesuchte String am Ende der Zeile stehen muss. Passt doch.
Wo liegt das Problem???

Gruß Peter
 
OP
Escho

Escho

Advanced Hacker
Also, beim rm mit dem grep finde ich auch nichts außergewöhnliches. Das läuft, außer es sind nur noch Dateien mit .mpg vorhanden oder gar keine. Dann kommt natürlich die zu erwartende Fehlermeldung.

Edgar
 
J

jengelh

Guru
trommelpeter schrieb:
Kann den Denkfehler leider nicht erkennen. das $ markiert bei grep das der gesuchte String am Ende der Zeile stehen muss. Passt doch.
Wo liegt das Problem???
Zum Vergrößern anklicken....
Es mag ja Leute geben, die einfach rm -Rf nehmen und dann kann auch schonmal unbeabsichtigt ein Verzeichnis dabei mit weggehen.
 
A

abgdf

Guru
Hallo,

da ich in meinem Vorschlag nur ein einfaches "rm" und nicht "rm -r" verwendet hatte, werden durch den Befehl (mit dem grep) keine Verzeichnisse gelöscht.

Das Beispiel
Code: 
touch wichtig.txt
touch `echo -en "wichtig.txt\nwichtig.mpg"`
rm $(ls | grep -v ".mpg$")
verstehe ich nicht so ganz. Wieso wird das "wichtig.txt" denn zweimal getoucht ?
Außerdem funktioniert das doch prima: Nach dem "rm ..." ist "wichtig.mpg" noch da, alle übrigen Dateien in dem Verzeichnis sind weg.
Das war es doch, was der OP wollte.

Aber an dem "find ..." ist natürlich auch nichts auszusetzen.

Allgemein hatte ich mal zu "grep" geschrieben:
Bestimmte Zeilen aus Texten und Befehlsausgaben heraussuchen: grep

Der Befehl "grep" durchsucht einen mehrzeiligen Text nach einem Suchwort oder einem Suchmuster und gibt die gefundenen Zeilen auf dem Bildschirm aus.

Der zu durchsuchende Text kann insbesondere die Ausgabe eines anderen Befehls sein, die über eine Pipe "grep" zugeleitet wird. Zum Beispiel gibt ein einfaches "find" die Namen aller Dateien, Verzeichnisse und Unterverzeichnisse im aktuellen Verzeichnis als mehrzeiligen Text aus. Auf diese Ausgabe kann man dann "grep" anwenden, um nur diejenigen Dateien und Verzeichnisse angezeigt zu bekommen, deren Name einen bestimmten Text enthält. So zeigt

find | grep html

nur solche Dateien und Verzeichnisse im aktuellen Verzeichnis, deren Name "html" enthält.

Im obigen Beispiel würden jedoch auch Dateien gefunden, deren Name "html" in der Mitte enthält. Um noch gezielter suchen zu können unterstützt "grep" auch reguläre Ausdrücke als Suchmuster. So findet

find | grep 'html$'

nur Dateien und Verzeichnisse, deren Name auf "html" endet.

Ruft man nur "grep" mit einem Suchwort (oder Suchmuster) und einem Dateinamen auf, so wird die angegebene Datei nach dem Suchstring durchsucht, und die gefundenen Zeilen werden ausgegeben. Der Befehl

grep -ir wort *

durchsucht demnach alle Dateien im aktuellen Verzeichnis und allen Unterverzeichnissen ("grep"-Option "-r"), die den Begriff "wort" enthalten, wobei Groß-/Kleinschreibung ignoriert wird ("grep"-Option "-i"). Die gefundenen Zeilen und der Name der Dateien, in denen sie gefunden wurden, werden ausgegeben. Das ist recht praktisch, wenn man in einem Verzeichnis nach einer (Text-)Datei mit einem bestimmten Inhalt sucht.
Zum Vergrößern anklicken....

Gruß
 
regexer

regexer

Advanced Hacker
abgdf schrieb:
Das Beispiel
Code: 
touch wichtig.txt
touch `echo -en "wichtig.txt\nwichtig.mpg"`
rm $(ls | grep -v ".mpg$")
verstehe ich nicht so ganz. Wieso wird das "wichtig.txt" denn zweimal getoucht ?
Zum Vergrößern anklicken....
Ich vermute mal, jengelh wollte damit sagen, dass es gefährlich ist, per Shell-Evaulation Argumente an rm zu übergeben. Falls z.B. eine Datei ein Space im Namen hat würde das als zwei Dateien an rm übergeben werden. Noch dümmer wäre, wenn ein Dateiname mit Minus beginnt. Das würde nämlich dann als Option interpretiert werden. Und zuletzt interpretiert grep den Punkt im Suchstring als beliebiges Zeichen.
Mein Beispiel mit ls (bevor hier noch etwas schlimmes passiert) ...
Code: 
prompt> mkdir test
prompt> cd test
prompt> touch -- -l wichtig.txt "wichtig.txt wichtig.mpg"
prompt> ls $(ls)
/bin/ls: wichtig.mpg: No such file or directory
-rw-r--r-- 1 user group 0 May 12 8:50 wichtig.txt
-rw-r--r-- 1 user group 0 May 12 8:50 wichtig.txt
prompt>
Übungs-Fragen: ;)
1. Warum reagiert ls so, als wäre der Parameter "-l" angegeben worden? Der steht doch nirgendwo!
2. Woher kommt die Fehlermeldung "No such file or directory"?
3. Warum wird die Datei "wichtig.txt" zwei mal gelistet?

Deswegen: Solche Sachen besser sauber mit find lösen...
 
regexer

regexer

Advanced Hacker
Ergänzend zum rm-ls-grep-Problem, habe ich versucht, jengelhs Beispiel entsprechend zu adaptieren...
Code: 
prompt> mkdir test
prompt> cd test
prompt> touch wichtig.mpg "wichtig.mpg wichtig.txt" wichtig.txt xmpg
prompt> ls -l
-rw-r--r-- 1 user group 0 May 13 11:50 wichtig.mpg
-rw-r--r-- 1 user group 0 May 13 11:50 wichtig.mpg wichtig.txt
-rw-r--r-- 1 user group 0 May 13 11:50 wichtig.txt
-rw-r--r-- 1 user group 0 May 13 11:50 xmpg
prompt> rm $(ls | grep -v ".mpg$")
rm: cannot remove `wichtig.txt': No such file or directory
prompt> ls -l
-rw-r--r-- 1 user group 0 May 13 11:50 wichtig.mpg wichtig.txt
-rw-r--r-- 1 user group 0 May 13 11:50 xmpg
prompt>

Wir stellen fest:
1. wichtig.mpg ist gelöscht, obwohl wir das nicht wollten.
2. "wichtig.mpg wichtig.txt" hat überlebt, obwohl wir das nicht wollten.
3. xmpg hat überlebt, obwohl wir das nicht wollten.

Ergo:
Man nehme find usw.
 
A

abgdf

Guru
Ach so war das gemeint. Alles klar :idea:.

Dann also doch lieber "find" (auch um den Geisteszustand wiederherzustellen :wink:).
 
T

trommelpeter

Member
Jetzt kommt mir aber noch eine Frage die mich schon länger interessiert.

Was ist eigentlich der Unterschied ob man
so
Code: 
rm $(ls | grep -v ".mpg$")
oder so
Code: 
rm `ls | grep -v ".mpg$"`
schreibt?

Die zweite Möglichkeit, so habe ich das gelernt.
 
regexer

regexer

Advanced Hacker
trommelpeter schrieb:
Was ist eigentlich der Unterschied ob man
so
Code: 
rm $(ls | grep -v ".mpg$")
oder so
Code: 
rm `ls | grep -v ".mpg$"`
schreibt?
Zum Vergrößern anklicken....
Kurz gesagt: Keiner!

Lang gesagt: Die Backticks-Lösung dürfte älter sein, und ist deswegen auch in anderen Shells (ksh, bsh) vertreten. Die Klammer-Lösung lässt sich außerdem besser schachteln.
 
A

abgdf

Guru
Ich finde auch, die Klammerlösung sieht etwas lesbarer und damit etwas weniger kryptisch aus (worauf ich als "Pythoniac" schon Wert lege :)).
Aber das ist natürlich Geschmackssache :p.
 
T

trommelpeter

Member
Ich habe mir das Scripting weitestgehend aus diesem Buch
http://www.pditchen.de/Skript-Buch/skript-buch.html
beigebracht.
Aber ich fange immer wieder gerne neue Tipps ein.
Man lernt nie aus.

Gruß Peter
 
OP
Escho

Escho

Advanced Hacker
jengelh schrieb:
Aber einige machen den selben Fehler immer wieder ...
Zum Vergrößern anklicken....
Zum Beispiel, weil sie die Konsequenzen nicht erkennen können oder mit diesen noch nicht konfrontiert worden sind.

Ich empfinde es als äußerst informativ, was sich aus meiner kleinen Anfrage da so alles entwickelt hat.

Edgar
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben