find – Die Schatenseite

Schlagwort: find

Alte Dateien aufsummieren, oder: find ohne xargs

31.10.2019 by Ronald·Keine Kommentare

Wer öfter mal was in der Shell macht kennt vermutlich das Kommando find. Damit kann man sehr flexibel Dateien oder Verzeichnisse auf der Festplatte suchen. So findet man zum Beispiel alle Dateien die älter sind als 100 Tage:

find . -type f -mtime +100

1	find . -type f -mtime +100

Um die Größen aller Dateien zu bekommen kann man find bitten für jede Datei ein du (Disk Usage) auszuführen:

find . -type f -mtime +100 -exec du -b {} \;

1	find . -type f -mtime +100 -exec du -b {} \;

Kann man machen, aber das bedeutet dass find für jede einzelne Datei ein Kommando startet. Jetzt braucht du nicht sehr lange für die Ausführung, aber wenn man stattdessen beispielsweise jeweils ein Perl-Skript starten muss wirkt sich das sehr negativ aus.

Wenn man nur wenige Fundstellen erwartet kann man folgendes machen:

du -b $(find . -type f -mtime +100)

1	du -b $(find . -type f -mtime +100)

So wird vor der Ausführung von du die Klammer expandiert und durch die Ausgabe von find ersetzt. Das hat aber einen bedeutenden Haken: wenn sehr viele Dateien gefunden werden wird die Kommandozeile zu lang die man durch die Expansion erhält („-bash: /usr/bin/du: Argument list too long“) — Zeilen dürfen nicht beliebig lang werden (man findet die zulässige Länge mit getconf ARG_MAX, muss von der Zahl aber noch die Größe der Umgebungsvariablen abziehen).

Um das zu umgehen ruft man klassisch xargs zur Hilfe. Das sieht dann so aus:

find . -type f -mtime +100 -print0 | xargs -0 du -b

1	find . -type f -mtime +100 -print0 \| xargs -0 du -b

Jetzt findet find alle gesuchten Dateien und gibt deren Namen nullterminiert nach STDOUT. Von da liest xargs ein und baut eine Kommandozeile mit du -b. In diese Zeile werden so viele der eingegebenen Strings reingepackt wie möglich bevor du ausgeführt wird.

Aber find braucht offenbar kein xargs

Man kommt — und das weiss ich erst neuerdings — auf das gleiche Ergebnis wenn man in find statt des Semikolons ein Pluszeichen benutzt:

find . -type f -mtime +100 -exec du -b {} +

1	find . -type f -mtime +100 -exec du -b {} +

Keine Ahnung wie das bislang an mir vorübergehen konnte, das macht einiges eleganter.

Wie komme ich jetzt an die Summe der Fundstellen?

Wenn man folgendes schreibt berechnet du für jeden Aufruf eine Summe, mit dem grep kann man sich die ansehen:

find . -type f -mtime +100 -exec du -bc {} + | grep total

1	find . -type f -mtime +100 -exec du -bc {} + \| grep total

Bei vielen Dateien wird du mehrfach aufgerufen, man bekommt also mehrere Summen. In meinem Beispiel finde ich gut 45000 Dateien, find ruft dafür 19 Mal du auf, grep gibt mir also 19 Zeilen mit jeweils einer ziemlich großen Zahl. Die gilt es aufzusummieren, das geht am einfachsten mit awk:

find . -type f -mtime +100 -exec du -bc {} + | awk '/total/{ total += $1 }; END { print total }'

1	find . -type f -mtime +100 -exec du -bc {} + \| awk '/total/{ total += $1 }; END { print total }'

Jetzt bekomme ich nur noch eine sehr große und sehr unleserliche Summe, die gibt mir die Summe der Größe aller gefundenen Dateien. Die kann awk mir in GB umrechnen:

find . -type f -mtime +100 -exec du -bc {} + | awk '/total/{ total += $1 }; END { print total / (2**(30)) " GB" }'

1	find . -type f -mtime +100 -exec du -bc {} + \| awk '/total/{ total += $1 }; END { print total / (2**(30)) " GB" }'

Somit habe ich einen leserlichen Wert, damit kann ich arbeiten.

Wenn es einen einfacheren Weg zum Ziel gibt: ich bin immer für Vorschläge offen!

Dateien suchen mit Windows

03.04.2012 by Ronald·2 Kommentare

Kurz gesagt: es geht nicht.

Zumindest nicht wenn man den Anspruch erhebt auch etwas finden zu wollen.

Die Langversion: Bei der Arbeit bin ich einfacher Benutzer. Kein Administrator. Zumindest nicht auf meinem Arbeitsplatzrechner, einem PC mit Windows XP. Das Ding hat mich schon eine Menge Nerven gekostet, aber das Heute schlägt dem Fass die Krone ins Gesicht.

Vor ein paar Jahren habe ich mich damit abfinden müssen dass ich mit dem Explorer nicht im Inhalt von Dateien suchen kann. Zumindest nicht in irgendwelchen dahergelaufenen Dateien. Ich hatte einen Verzeichnisbaum voll mit PHP-Sourcen, und ich wollte die Datei finden in der eine bestimmte Meldung ausgegeben wird. Ein Fall für grep -r "Meldung" * — auf jedem nicht-Windows zumindest.

Windows sucht — wenn ich mich recht erinnere — erstmal nur in indizierten Dateien. Nach längerer Suche hat mir ein automatisch übersetzter Artikel in der Knowledge Base etwas in der Art „schalt die Indizierung ab, dann funktioniert das auch mit Dateien deren Endung Windows nicht kennt“ gesagt. Einschliesslich einer Anleitung wo der erforderliche Haken versteckt ist. Bei mir war der Haken aber ausgegraut, ich schätze dass das ein fürsorglicher Administrator für mich erledigt hat. Ergo: suchen per Explorer habe ich mir abgewöhnt.

Stattdessen an der Kommandozeile findstr aufgerufen. Das geht zur Not sogar rekursiv, hat mir damals also den Weg zur gesuchten Datei gezeigt.

Heute hat mich aber auch findstr enttäuscht:

findstr findet nichts

Wir sehen eine Textdatei mit einer Zeile Text. Mit findstr kann ich offenbar nicht nach einem Wort suchen. Ein Kollege empfiehlt find. OK, solange ich nicht nach Mustern suchen will klappt das offenbar. Aber was ist das? Wenn ich nach einzelnen Buchstaben suche findet auch findstr etwas! Allerdings mit komischen Zeichen dazwischen…

Sowohl type und find an der Kommandozeile, als auch Notepad und Wordpad können mir den Inhalt der Datei sauber anzeigen. Nur halt findstr nicht.

Aber die komischen Zeichen sind ein Hinweis: mit Vim (ohne den würde ich eingehen) finde ich heraus dass das Fileencoding dieser Datei utf-16le ist. Keine Ahnung wie es dazu gekommen ist, ich bin mir sicher dass ich die Datei mit Bordmitteln erstellt habe. Ursprünglich war das eine RDP-Datei, mit der ich direkt die Verbindung zu einem bestimmten Rechner starten kann.

Fazit: findstr ist auch keine Lösung. Solange ich nichts spezielles will (z. B. nach Mustern suchen. Oder rekursiv in Verzeichnissen. Oder in Datenströmen.) scheint find den Dienst zu tun.

In diesem Fall hat mir Vim das Encoding verraten. Unter Linux hätte es wahrscheinlich auch ein file getan (ungetestet). Wie finde ich eigentlich unter Windows das Encoding einer Textdatei heraus?