[gelöst] Dateien löschen mit rm

[Escho]

Guten Morgen!

Mit rm lassen sich ja in einem Verzeichnes alle Dateien löschen:

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

 

[jengelh]

find verzeichnisname -maxdepth 1 ! -iname "*.mpg" -print0 | xargs -0 rm -v

 

[Escho]

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

 

[abgdf]

Vielleicht ist

rm $(ls | grep -v ".mpg$")

etwas leichter zu verstehen ...

 

[Escho]

Vielleicht ist

rm $(ls | grep -v ".mpg$")

etwas leichter zu verstehen ...

Nicht unbedingt, da ich es bisher erfolgreich vermieden habe, mich mit grep herumzuschlagen. Also neu ist neu.
Macht aber nichts, denn ich weiß nun, daß es geht und wo ich ansetzen muß.

Edgar

 

[jengelh]

Vielleicht ist

rm $(ls | grep -v ".mpg$")

etwas leichter zu verstehen ...

Bist du des Wahnsinn!

touch wichtig.txt
touch `echo -en "wichtig.txt\nwichtig.mpg"`
rm $(ls | grep -v ".mpg$")

 

[Escho]

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

 

[trommelpeter]

Bist du des Wahnsinn!

Code:

touch wichtig.txt
touch `echo -en "wichtig.txt\nwichtig.mpg"`
rm $(ls | grep -v ".mpg$")

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

 

[Escho]

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

 

[jengelh]

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???

Es mag ja Leute geben, die einfach rm -Rf nehmen und dann kann auch schonmal unbeabsichtigt ein Verzeichnis dabei mit weggehen.

 

[abgdf]

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

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.

Gruß

 

[regexer]

Das Beispiel

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 ?

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) ...

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]

Ergänzend zum rm-ls-grep-Problem, habe ich versucht, jengelhs Beispiel entsprechend zu adaptieren...

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.

 

[abgdf]

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

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

 

[trommelpeter]

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

Was ist eigentlich der Unterschied ob man
so

rm $(ls | grep -v ".mpg$")

oder so

rm `ls | grep -v ".mpg$"`

schreibt?

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

 

[regexer]

Was ist eigentlich der Unterschied ob man
so

rm $(ls | grep -v ".mpg$")

oder so

rm `ls | grep -v ".mpg$"`

schreibt?

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.

 

[abgdf]

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 .

 

[trommelpeter]

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

 

[jengelh]

Man lernt nie aus.

Aber einige machen den selben Fehler immer wieder ...

 

[Escho]

Aber einige machen den selben Fehler immer wieder ...

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