by ·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:

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

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:

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:

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:

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:

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:

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:

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! :-)

by ·Keine Kommentare

Traditionell bewege ich mich viel in der Shell, und da habe ich es oft mit verschiedenen Datenformaten zu tun die ich lesen oder schreiben möchte. Lesen ist mittlerweile vergleichsweise einfach: jq für JSON, XMLStarlet für XML.

Wie man sinnvoll XML generiert weiss ich noch nicht, aber vor ein paar Tagen hat Jan-Piet Mens ein Tool veröffentlicht mit dem man sauber JSON generieren kann: jo (hier bei Github).

Ausprobiert habe ich das noch nicht, aber die Beschreibung sieht sehr vielversprechend aus. Gerade in Verbindung mit dem Monitoring-Tool meiner Wahl — Zabbix — hätte ich mit so einem Tool im Werkzeugkasten einiges deutlich eleganter schreiben können…

by ·Keine Kommentare

Eine alte Weisheit besagt folgendes:

Wenn man erstmal einen Hammer in der Hand hat sieht alles aus wie ein Nagel.

Wenn man also halbwegs mit dem gängigen Unix-Werkzeugkasten (grep, cut, sed und awk) umgehen kann ist man geneigt diese Tools immer einzusetzen wenn Informationen aus Dateien zu extrahieren sind. Damit auf strukturierte Daten loszugehen ist allerdings nicht nur fehlerträchtig sondern auch alles andere als elegant.

Vor längerer Zeit habe ich hier mal auf jq hingewiesen. Das ist die Lösung wenn man in seiner Eigenschaft als Shell-Skript Daten aus JSON-Datensätzen braucht, mittlerweile konnte ich da schon einige Male drauf zurück greifen.

Jetzt habe ich was vergleichbares für XML-Daten gesucht, und wie es aussieht ist XMLStarlet das Werkzeug der Wahl (Disclaimer: ich habe nicht lange gesucht, NOCH bin ich für Gegenvorschläge offen ;-) ).

Erste Anwendung ist wieder, einen ungetrübten Blick auf das gewählte Dokument zu werfen. Mein Feed ist ein insofern ein schlechtes Beispiel als dass der Code ziemlich sauber formatiert ist, aber der Trick wird klar (die Sache mit dem Backslash am Zeilenende setze ich mal voraus):

Als nächstes interessieren mich vielleicht die Titel der letzten Artikel. Dazu selektiere ich alles was auf den XPath //rss/channel/item matched, und lasse mir jeweils den Wert von title ausgeben. Gefolgt von einem Zeilenumbruch:

Aber wann habe ich denn meinen letzten Artikel veröffentlicht? Dazu matche ich nur auf das erste Element und lasse mir davon das pubDate geben, zur besseren Lesbarkeit wieder gefolgt von einem Zeilenumbruch:

Abschließend wüsste ich gerne noch worum es in meinem letzten Artikel ging. Auch das können wir formschön aus dem Feed extrahieren, allerdings wird das Kommando natürlich entsprechend unübersichtlicher. Wir matchen wieder auf das erste Item, lassen uns den Titel und einen Zeilenumbruch geben. Dann matchen wir innerhalb des Items (!) auf category. Dem Inhalt dieser Felder stellen wir jeweils einen Spiegelstrich voran, die Zeile beenden wir wieder mit dem Zeilenumbruch. So sieht das Kommando dann fertig aus:

Das Netz hält einige Artikel mit Beispielen parat, aber genau wie dieser Text kratzen die nur an der Oberfläche. XMLStarlet ist sicher ein Spielzeug mit dem man sich bei Gelegenheit mal länger auseinandersetzen sollte. Zumindest macht es den Standard-Werkzeugkasten im Umgang mit XML-Daten absolut obsolet.

by ·3 Kommentare

Fortschritt durch pkill

Fortschritt durch pkill

Letztes Wochenende habe ich wieder mal ein ISO-Image auf eine SD-Karte geschrieben, wie üblich an der Kommandozeile mit dd. Es ging um ein größeres Image, also hatte ich eine Menge Zeit um mich darüber zu ärgern dass ich den Fortschritt nicht sehe.

Heute habe ich einen Tweet gesehen der sagt dass man da in Zukunft eine Option für haben wird. Aber da wurde auch ein Workaround erwähnt den ich noch nicht kannte: mit pkill -USR1 dd kann man dem laufenden Prozess ein freundliches Signal schicken, daraufhin spuckt der seinen aktuellen Fortschritt aus. Wie das aussieht zeigt der Screenshot.

Fortschritt durch Tunnel

Fortschritt durch Tunnel

Eine andere Möglichkeit — optisch schicker, aber man das Tool ist nicht überall installiert — stellt der Pipe Viewer (pv) dar. Da teilt man sein dd auf zwei Kommandos auf und setzt das pv dazwischen.

Technisch ist das vielleicht nicht der optimale Weg, nett ist aber dass man damit universell Pipes überwachen kann, nicht nur für dd. Die Manpage hat ein paar interessante Beispiele.

by ·4 Kommentare

Eine interessante kleine Aufgabenstellung: ein Skript hat versehentlich tausende von Dateien mit einer verkehrten Extension generiert. Alle Dateien heissen .jpgjpg statt einfach nur .jpg. Gestandene Shell-Benutzer reparieren sowas natürlich mit einem formschönen Einzeiler. Das ist einfach, und eigentlich lohnt es sich nicht da lange drüber nachzudenken. Es sei denn man kommt auf die Idee, das zeitlich zu optimieren…

Im konkreten Fall — es geht um etwa 6000 Dateien — dauert die Optimierung länger als das was an Laufzeitgewinn rauskommt. Wenn wir also schon keine Zeit gewinnen, dann wenigstens Erkenntnis. :-)

Also, mein erster Ansatz ist es intuitiv, alle Dateien zu suchen, für jede Datei den neuen Namen festzulegen und dann umzubenennen. Machen wir eine Trockenübung bei laufender Stopuhr:

Das führt zu einer Laufzeit von erstaunlichen 21,443 Sekunden!

Halbwegs moderne Shells wie die Bash beherrschen Stringmanipulation, dazu muss man nicht zwingend auf sed zurückgreifen. Im TLDP steht wie es geht, so finde ich dort unter ‚Substring Removal‘ den richtigen Ansatz:

Das drückt die Zeit für die gleichen Testdaten schon auf 0,811 Sekunden. Soweit ich weiss haben wir uns damit zwar einen Bashismus eingehandelt, aber das ist heutzutage vielleicht schon egal.

Wenn wir aber schon Kompatibilität aufgeben können wir — schliesslich sind wir in einer hochmodernen Zsh — gleich in die Vollen gehen:

Ich habe noch nie rekursives Globbing (die zsh-lovers-Manpage hat mir verraten wie das geht) benutzt, aber nach nur 0,165 Sekunden war klar: es funktioniert. :-)

Oh, da man hier auch denken könnte dass das Betriebssystem den Dateibaum cached: nein, das ist nicht so. Wenn ich die Einzeiler mehrfach absetze, auch in anderen Reihenfolgen, kommen immer wieder vergleichbare Ergebnisse raus.

Da die effizienteste Methode auch gleichzeitig die am schnellsten zu tippende ist denke ich, dass die — wenn ich auswendig gewusst hätte wie das geht — in jeder Hinsicht die erste Wahl gewesen wäre. Aber ich kenne mich: wenn ich das ein paar Tage nicht benutze muss ich erst wieder recherchieren. Und dann falle ich doch wieder auf das bewährte sed zurück…

by ·Ein Kommentar

Heutzutage fallen an allen möglichen Stellen irgendwelche Daten im JSON-Format an. Und das ist gut so. Trägt nicht so auf wie XML, ist dafür aber flexibler — und vor allem besser definiert — als irgendwelche selbstausgedachten CSV- oder INI-Formate.

Man ist schlecht beraten, zu versuchen dermassen komplexe Formate mit Shell-Tools wie awk, sed oder grep zu Leibe zu rücken. Reguläre Ausdrücke sind eine tolle Sache, aber in dieser Situation fallen die einem früher oder später auf den Fuß. Bislang habe ich meist eine Sprache mit P bemüht: Python, Perl oder zur Not PHP. Die können JSON importieren, danach arbeitet man auf den gewohnten Datenstrukturen. Also auf Arrays und Objekten, und die kann man schön sauber nach dem durchkämmen was man sucht.

Jetzt hat aber ein neues Tool seinen Weg in meinen Werkzeugkasten gefunden: jq. weiterlesen

by ·Keine Kommentare

Nur ganz kurz: ich habe schon öfter die Herausforderung gehabt, in Shell-Skripten human-readable Dateigrößen in Bytes umzurechnen, damit man den Wert einfach ans Monitoring übergeben kann.
Bislang habe ich das Problem immer mit einer Hand voll Awk beworfen. Heute habe ich ein passendes Tool gefunden, und man kann sogar einstellen ob man Geek-Kilo oder normale Kilo haben will:

% echo 1234K | numfmt --from=si
1234000
% echo 1234K | numfmt --from=iec
1263616

Auf einem etwas angestaubten Debian (Squeeze) habe ich dieses Tool noch nicht, auf aktuelleren Systemen gehört das aber offenbar zu den coreutils. Kennt jemand eine bessere Lösung?

by ·3 Kommentare

Ich glaube ich erwähnte es schon: eines meiner Steckenpferde bei der Arbeit ist das Monitoring, also die Überwachung von Rechnern. Bei bestimmten Überwachungen bietet es sich an, den überwachten Rechner seine Messwerte selbst schicken zu lassen. Oft heißt es „es reicht wenn wir den Wert alle fünf Minuten kriegen“, also bietet sich ein Cronjob mit einem geschickt platzierten „*/5“ an.

Nachteil dabei: unter Umständen wird das Monitoring genau alle fünf Minuten zeitgleich mit hunderten Werten von hunderten Rechnern beworfen.

Um das zu entzerren habe ich mir was formschönes ausgedacht:

Diese Zeile bewirkt am Anfang eines Skriptes, dass vor der Ausführung eine variable Zeit gewartet wird. Das charmante daran: die Zeit ist abhängig vom Hostnamen, dem Skriptnamen und den Parametern die dem Skript übergeben werden. Es ist keine wirklich zufällige Zeit, das heißt dass man sich darauf verlassen kann dass das Skript ziemlich genau alle fünf Minuten einen Wert ausgibt.

Oh, falls das cut irritiert: wenn ich die hexadezimale Prüfsumme einfach mit $((0x…)) dezimal mache kommt da unter Umständen ein negativer Wert raus. Meine sleep-Version unterstützt leider keine Zeitreisen… ;-)

Hat jemand einen Vorschlag wie ich das noch eleganter hinkriegen würde?

EDIT: Vielleicht ist diese Variante noch schöner. Man umgeht mit Awk den ‚bashismus‘ mit dem Modulo, dafür spart man sich aber auch den Aufruf von cut.

by ·Keine Kommentare

Vor einer Weile habe ich auf Twitter einen netten Alias für die Shell gesehen:

alias doch='sudo $(history -p !-1)'

Das Ding geht nicht in der zsh, da das history-Kommando — anders als in der bash — hier kein p-Flag hat. Ist aber auch zweitrangig. Wenn man sein letztes Kommando doch mal mit Nachdruck (und root-Rechten) ausführen möchte geht auch ein beherztes:

sudo !!

An dieser Stelle nochmal ein Zitat zum Thema:

‚Multiple exclamation marks,‘ he went on, shaking his head, ‚are a sure sign of a diseased mind.‘
(Terry Pratchett in „Eric“)

Ich glaube auch Herr Pratchett würde die Anwendung mit sudo als Ausnahme durchgehen lassen, oder? :-)

by ·5 Kommentare

Heute habe ich mich (unter anderem) mit einem Problem beschäftigt das auf den ersten Blick trivial aussieht. Ich zumindest habe bislang keine Lösung gefunden die mir wirklich gefällt. Mal sehen ob was dabei rauskommt wenn ich das hier ‚crowdsource’… :-)

Aufgabenstellung: Zähle, wie viele Prozesse eines bestimmten Programmes schon länger als 30 Minuten laufen.

Klingt einfach, oder?

Die Ausgaben von ps zu parsen erscheint mir dabei aber zu fehleranfällig. Da müsste man zu viel berücksichtigen: Prozesse die vielleicht länger als einen Tag laufen, Prozesse die über Mitternacht gelaufen sind… ich habe nicht getestet wie es aussieht wenn man an der Zeitzone rumspielt… Nein, das kann nicht der richtige Ansatz sein.

Meine erste echte Lösung sieht zwar hässlich originell aus, funktionierte aber im Test (zu Demozwecken suche ich mal nach meinem Firefox):

echo | killall -i --older-than 30m firefox 2> /dev/null | tr -cd '?' | wc -c

Mit -i ist killall ‚interaktiv‘, fragt also zu jedem gefundenen Prozess freundlich nach ob es zuschlagen soll. Mit dem reingepipten echo beantwortet es sich diese Frage immer negativ. Der Rest der Zeile zählt im Prinzip wie oft killall gefragt hat ob es töten soll.

Blöd ist, dass die auf einem etwas älteren RHEL laufen soll. Anders als bei Ubuntu kennt killall da die Option –older-than noch nicht.

Der zweite Lösungsansatz funktioniert leider nur auf den ersten Blick, dafür aber auch auf dem alten Red Hat:

find /proc/[0-9]* -maxdepth 1 -name status -mmin +30 | xargs egrep "^Name:\sfirefox$" | wc -l

Ich suche also alle Prozesse die schon länger als 30 Minuten laufen, und suche in deren status-Datei nach dem Namen meines Prozesses. Die Ergebnisse werden dann wieder gezählt. Alternativ könnte man statt in der status- auch in der cmdline-Datei suchen, in meinem echten Einsatz übersehe ich damit dann auch Zombies (die werden separat betrachtet). Leider funktioniert dieser Ansatz nicht wirklich zuverlässig. Es sieht so aus als ob der Kernel den Dateien im Proc-Verzeichnis bisweilen einen neuen Timestamp gibt — obwohl der Prozess nicht gestartet oder beendet wurde. Ein Schuss in den Ofen, also. :-(

Wie macht man sowas? Ich meine, wenn man eine zuverlässige Lösung mit Bordmitteln haben will? Gibt es da ein passendes Tool das ich noch nicht kenne? Oder hilfreiche Optionen für gängige Tools? Wenn ich die Suchmaschine meiner Wahl frage finde ich eine Menge Lösungen, aber die sind entweder auch wackelig, oder sie bestehen darauf direkt alles zu töten…