Damit kommt aber auch die Version im Kurztipp klar.
Die verbesserte Version macht Folgendes anders/besser: die Ursprungsversion startet für jede gefundene Datei einen rm-Prozess, die verbesserte Version nimmt alle gefundenen Dateien zusammen und übergibt sie einem (wenn nötig, aber auch mehreren) rm-Prozess als Parameter. Deshalb wurde auch von "leicht optimierter Version" geschrieben.
> -print0 hängt an jeden gefundenen Dateinamen eine 0 ran,
Das ist ungenau formuliert: die Aktion -print – die auch die Standard-Aktion ist, falls keine andere angegeben wurde – gibt alle gefundenen Pfadnamen durch Zeilenumbruch getrennt auf der Standardausgabe aus, sprich je einen Pfadnamen pro Zeile; -print0 macht dasselbe, trennt die Pfadnamen jedoch nicht durch Zeilenumbrüche sondern durch Nullbytes (0x00 und nicht etwa das Zeichen "0"!).
> und xargs -0 sagt dem rm Kommando, das jeder Dateiname auf 0 endet.
Das ist komplett falsch. -0 ist eine Option von xargs, rm hat damit genau gar nichts zu tun. Die Option -0 sagt xargs, dass die auf der Standardeingabe übergebenen Pfadnamen durch Nullbytes und nicht durch Zeilenumbrüche getrennt sind, wie es eigentlich die Standards vorschreiben.
Der Unterschied zwischen dieser Version und der ursprünglichen ist, dass die ursprüngliche Version für jeden gefundenen Pfadnamen einen eigenen rm-Prozess startet, während diese Version nur soviele rm-Prozesse startet, wie unbedingt nötig, z. B. aufgrund von Beschränkungen der Anzahl der Argumente, die an einen Prozess übergeben werden können, Beschränkungen der maximalen Länge der Kommandozeile u. s. w.
Der große Nachteil der neuen Version ist allerdings, dass sie eine proprietäre, nicht-standardisierte Erweiterung von GNU find und GNU xargs verwendet, so dass diese Version mit anderen Implementierungen nicht funktioniert.
Eine alternative Möglichkeit wäre die Verwendung der standardisierten POSIX-Syntax: find ~/.thumbnails -type f -atime +14 -exec rm '{}' +, also mit dem Plus-Zeichen "+" als Abschluss des Befehls anstatt des Semikolons ";".
> Diese Version kommt auch mit Leerzeichen und Sonderzeichen im Dateinamen klar.
Das kommt die ursprüngliche auch. Was du vermutlich meinst, ist die Variante find ~/.thumbnails -type f -atime +14 -print | xargs rm. Diese hat zwar auch kein Problem mit Leerzeichen und Sonderzeichen im Pfadnamen, aber mit Zeilenumbrüchen im Pfadnamen kommt sie nicht klar, denn schließlich dient der Zeilenumbruch ja als Trenner für die Pfadnamen-Liste. Das einzige Oktett, welches in einem Pfadnamen nicht vorkommen kann, ist 0x00. Alles andere ist erlaubt.
Außerdem könnte man noch klugscheissen, dass das Null-Byte daher kommt, dass es in einem "String" in C das Ende markiert.
Weiterhin könnte man noch erwähnen, dass man aus Sicherheitsgründen lieber execdir statt exec verwenden sollte, was aber leider wiederum nicht zum POSIX-Standard gehört, aber das muss man jetzt nicht auch noch im Einzelnen vorkauen, denn ein Verweis auf die Info- oder auch Man-Pages von find ist viel besser.
Die Syntax mit -exec ... + wurde "erst" vor fünf Jahren standardisiert. Da kann man nicht erwarten, dass die GNU-Jungs das so "schnell" implementieren; man braucht also eine relativ neue Version der GNU findutils. Die Version, die in Debian 3.1 enthalten ist, reicht z. B. AFAIK nicht aus.
Alternativ kann man man auch eine andere Implementierung verwenden; Jörg Schillings sfind etwa unterstützt das schon seit Jahren.
Übrigens lässt sich dieses Verhalten auch bei neueren (GNU-only?) find-Versionen folgendmassen erreichen:
-exec command {} + This variant of the -exec option runs the specified command on the selected files, but the command line is built by appending each selected file name at the end; the total number of invocations of the command will be much less than the number of matched files. The command line is built in much the same way that xargs builds its command lines. Only one instance of {} is allowed within the command. The command is executed in the starting directory.
Bei mir sind es knapp 2GB und ich bin bestimmt nicht behandlungsbedürftig. Wer eine Digitalkamera sein eigen nennt und große Thumbnails benutzt, kommt da bald an.
Von Michael Lehmeier am Do, 9. März 2006 um 10:50 #
Auf die Gefahr hin etwas offensichtliches zu sagen:
Hast du Thumbnails überhaupt aktiviert? Nicht nur bei der Ansicht, sondern dass sie permanent gespeichert werden? Ich z.B. nicht, ich habe nirgendwo Thumbnails.
Trotzdem interessant der Trick mit dem -print0! (obwohl ich mir nicht vorstellen kann wieso der funktioniert...)
Von Michael Lehmeier am Do, 9. März 2006 um 12:49 #
Sorry, ich glaube hab dich falsch verstanden. Ich dachte du meinst, dein Home-Verzeichnis hat vorher und nachher 132MB. Dachte nicht, dass du dein .thumbnails meinst. Dachte, du hast das Verzeichnis gar nicht.
Das geht auch nicht nur unter KDE... der sehr gute Bildbetrachter GQviev (gtk) hat sowas wie in den Kurztipp hier auch eingebaut... sogar mit Fortschrittsbalken
kann man das auch regelmaessig automatisch laufen lassen? wenn nicht, dann ist die zeile dort oben besser ansonsten haben die entwickler von kde mitgedacht.
Entweder hab ich es gelesen, oder es mir dazugedacht, das der Artikel auf einen neuen Cronjob hinweist, den man sinniger Weise für die Sache erstellen sollte... ^^
Mein $GRAPHICVIEWER speichert unter anderem in jedem verzeichnis ein .thumbnails (konfigurierbar ob dort oder unter .gqview/thumbnails). Dafür hilft dann ein
Zumindest für neuere Versionen von gqview ist das aber nicht mehr notwendig, da diese nur noch ~/.thumbnails benutzen (das andere Verhalten ist natürlich auch einstellbar).
Klar, aber ich finde es brauchbarer, wenn die Thumbnails pro Verzeichnis abgelegt werden. Da läßt sich besser der Platz eines einzelnen Albums bestimmen.
Irgendein Player aus den Staaten legt seine Vorschaubilder in der Datei Thumbs.db ab - wenn er z.B. per smb auf einen Linuxrechner zugreift . Der obige Aufruf leicht modifiziert bringt Klarheit
Wieso gibt es überhaupt "frische" und alte Thumnails? Wenn das Thumbnail erzeugt, so dachte ich, gibt es eine Zeitstempel. Wird der nun ständig beim bloßen angucken verändert oder wie weiß das System, daß ich die Thumbs xy schon längere Zeit nicht mehr in Großformat aufgerufen habe?
find ~/.thumbnails -type f -atime +14 -print0 | xargs -0 rm
Diese Version kommt auch mit Leerzeichen und Sonderzeichen im Dateinamen klar.
Gruss
Vielleicht kurz zur weiteren Erklärung: Ein Nullbyte, keine '0' (0x30).
Ansonsten: Korrekt. :)
lg
Erik
Die verbesserte Version macht Folgendes anders/besser:
die Ursprungsversion startet für jede gefundene Datei einen rm-Prozess,
die verbesserte Version nimmt alle gefundenen Dateien zusammen und übergibt sie einem (wenn nötig, aber auch mehreren) rm-Prozess als Parameter.
Deshalb wurde auch von "leicht optimierter Version" geschrieben.
Das ist ungenau formuliert: die Aktion -print – die auch die Standard-Aktion ist, falls keine andere angegeben wurde – gibt alle gefundenen Pfadnamen durch Zeilenumbruch getrennt auf der Standardausgabe aus, sprich je einen Pfadnamen pro Zeile; -print0 macht dasselbe, trennt die Pfadnamen jedoch nicht durch Zeilenumbrüche sondern durch Nullbytes (0x00 und nicht etwa das Zeichen "0"!).
> und xargs -0 sagt dem rm Kommando, das jeder Dateiname auf 0 endet.
Das ist komplett falsch. -0 ist eine Option von xargs, rm hat damit genau gar nichts zu tun. Die Option -0 sagt xargs, dass die auf der Standardeingabe übergebenen Pfadnamen durch Nullbytes und nicht durch Zeilenumbrüche getrennt sind, wie es eigentlich die Standards vorschreiben.
Der Unterschied zwischen dieser Version und der ursprünglichen ist, dass die ursprüngliche Version für jeden gefundenen Pfadnamen einen eigenen rm-Prozess startet, während diese Version nur soviele rm-Prozesse startet, wie unbedingt nötig, z. B. aufgrund von Beschränkungen der Anzahl der Argumente, die an einen Prozess übergeben werden können, Beschränkungen der maximalen Länge der Kommandozeile u. s. w.
Der große Nachteil der neuen Version ist allerdings, dass sie eine proprietäre, nicht-standardisierte Erweiterung von GNU find und GNU xargs verwendet, so dass diese Version mit anderen Implementierungen nicht funktioniert.
Eine alternative Möglichkeit wäre die Verwendung der standardisierten POSIX-Syntax: find ~/.thumbnails -type f -atime +14 -exec rm '{}' +, also mit dem Plus-Zeichen "+" als Abschluss des Befehls anstatt des Semikolons ";".
> Diese Version kommt auch mit Leerzeichen und Sonderzeichen im Dateinamen klar.
Das kommt die ursprüngliche auch. Was du vermutlich meinst, ist die Variante find ~/.thumbnails -type f -atime +14 -print | xargs rm. Diese hat zwar auch kein Problem mit Leerzeichen und Sonderzeichen im Pfadnamen, aber mit Zeilenumbrüchen im Pfadnamen kommt sie nicht klar, denn schließlich dient der Zeilenumbruch ja als Trenner für die Pfadnamen-Liste. Das einzige Oktett, welches in einem Pfadnamen nicht vorkommen kann, ist 0x00. Alles andere ist erlaubt.
jwm
Weiterhin könnte man noch erwähnen, dass man aus Sicherheitsgründen lieber execdir statt exec verwenden sollte, was aber leider wiederum nicht zum POSIX-Standard gehört, aber das muss man jetzt nicht auch noch im Einzelnen vorkauen, denn ein Verweis auf die Info- oder auch Man-Pages von find ist viel besser.
find: Fehlendes Argument für "-exec".
GNU find version 4.2.27 tuts bei mir jedenfalls.
Alternativ kann man man auch eine andere Implementierung verwenden; Jörg Schillings sfind etwa unterstützt das schon seit Jahren.
jwm
for HOME in /home/*; do find $HOME/.thumbnails/ -type f -atime +14 -print0 | xargs -0 rm; done
find /home/*/.thumbnails/ -type f -atime +14 -print0 | xargs -0 rm
-exec command {} +
This variant of the -exec option runs the specified command on the selected files, but
the command line is built by appending each selected file name at the end; the total
number of invocations of the command will be much less than the number of matched files.
The command line is built in much the same way that xargs builds its command lines.
Only one instance of {} is allowed within the command. The command is executed in the
starting directory.
Da wird aber manch unbedarfter Nutzer eine Menge Plattenplatz verschwenden.
Hast du Thumbnails überhaupt aktiviert?
Nicht nur bei der Ansicht, sondern dass sie permanent gespeichert werden?
Ich z.B. nicht, ich habe nirgendwo Thumbnails.
Trotzdem interessant der Trick mit dem -print0! (obwohl ich mir nicht vorstellen kann wieso der funktioniert...)
Ich dachte du meinst, dein Home-Verzeichnis hat vorher und nachher 132MB.
Dachte nicht, dass du dein .thumbnails meinst.
Dachte, du hast das Verzeichnis gar nicht.
Jo und dafür hat KDE ja ne Löschung vorgesehen und zwar in:
Kde Kontrollzentrum->Sicherheit(Security)->Privacy Haken bei Thumbnail Cache und cleanup ausführen.
Ich hoffe ihr bekommt jetzt nicht ne Flut von so kleinen Tipps geschikt so dass ihr für jeden Furz ne News schreibt:-)
Viele verwenden auch nur einen einfachen Windowmanager.
Eckhart
wenn nicht, dann ist die zeile dort oben besser ansonsten haben die entwickler von kde mitgedacht.
find ~ -type f -regex '.*/\.thumbnails/.*' -atime +14 -exec rm {} +
{} muß in bash zumindest nicht maskiert werden.
die sind schneller neugeneriert, als ein find die alle checkt ...
Jedenfalls die die ich noch brauche.
Mhmm...
sollt ich dann vllt weglassen