Die Moreutils ergänzen die Standard-Tools für die Shell um nützliche, aber zum Teil exotische Werkzeuge.

Die Shell macht es möglich: Hier kombinieren Sie unzählige kleine Werkzeuge, um komplexe Aufgaben ad hoc oder in Skripten zu lösen. In vielen Fällen genügen dafür die Coreutils aus dem Paket util-linux. Es gibt aber immer wiederkehrende Situationen, für die es bisher keine (Standard-)Lösungen in Form eines Tools gibt.

Für einige davon hat Joey Hess (mithilfe einiger Freunde) einen Satz an Programmen entwickelt, die unter dem Namen Moreutils [1] laufen. Die Tools fallen größtenteils recht speziell aus, sodass es durchaus sein kann, dass Sie noch nie von ihnen gehört haben. Wer sich allerdings des Öfteren auf der Befehlszeile herumtreibt, tut ganz gut daran, diese kleinen Programme im Hinterkopf zu behalten.

Die aktuelle Version der Moreutils umfasst 15 Programme (siehe Tabelle “Kategorien”). Bei allen handelt es sich um übersichtliche Werkzeuge mit wenigen Optionen, die jeweils eine klar umrissene Aufgabe erledigen. Da sie in Anlehnung an die klassischen Unix-Tools entwickelt wurden, verwenden sie eine analoge Syntax und folgen ähnlichen Konzepten. Alle verfügen über eine Manpage, die allerdings oft wenig aussagekräftig ausfällt.

Chronic

In manchen Situationen, etwa in Skripten oder einem Cronjob, stören die Ausgaben eines Programms. In diesen Fällen hilft chronic weiter. Der Befehl erwartet als Argument ein Programm, dessen Kanäle STDERR (Fehlerausgabe) und STDOUT (Standardausgabe) es so lange verwirft, bis tatsächlich ein Fehler auftritt. Zwar ließe sich dies auch klassisch durch das Konstrukt > /dev/null 2>&1 bewerkstelligen – allerdings ist es dann nicht möglich, die Ausgaben im Fehlerfall zu erhalten, da dieses Umleiten ins Null-Device sie ebenfalls gnadenlos verwirft. Das macht chronic besser.

Ein Beispiel soll das verdeutlichen: Mit dem Skript a2x wandeln Sie Text aus dem Format Asciidoc in andere Formate um. Normalerweise funktioniert das gut und fehlerfrei – dann benötigen Sie die vom Skript produzierten Ausgaben nicht. Allerdings treten gelegentlich doch Probleme auf, und dann hilft die Analyse der Ausgaben dabei, den Fehler zu finden.

Listing 1 zeigt ein entsprechendes Beispiel für den Einsatz von Chronic. Normalerweise erzeugt diese Befehlszeile einfach nur die gewünschte EPUB-Datei, ohne weitere Ausgaben zu erzeugen. Tritt allerdings ein Fehler beim Bearbeiten auf, erhalten Sie die gesamte Ausgabe auf den beiden Kanälen STDOUT und STDERR.

$ chronic a2x -v -fepub *.adoc

Zwei Optionen steuern das genaue Verhalten von Chronic: Mit -e (“STDERR triggering”) sorgen Sie dafür, dass es nicht den Rückgabewert des ausgeführten Programms auswertet, sondern anhand der Ausgaben auf STDERR entscheidet, ob Fehler auftraten. Voreingestellt entscheidet der Rückgabewert (ungleich null).

Über -v gibt Chronic etwas detailliertere Ausgaben aus, insbesondere den Rückgabewert des ausgeführten Programms. Es unterscheidet dabei zwischen Ausgaben auf STDERR und STDOUT des aufgerufenen Programms.

Ifne

Der Befehl ifne hat eine ähnliche Syntax wie chronic und startet ebenfalls das als Argument angegebene Programm. Allerdings wertet er die Standardeingabe aus, um zu entscheiden, ob es das Programm startet. Ohne Optionen startet Ifne das Programm nur dann, wenn der entsprechende Kanal nicht leer ist.

Listing 2 zeigt ein typisches Beispiel, das der Manpage entstammt. Der Administrator erhält hier eine E-Mail, falls das Find-Kommando mindestens eine Core-Datei findet. Dieser Ansatz liefert in der Nachricht direkt die ermittelten Pfade zu den Files mit.

$ find . -name core | ifne mail -s "Core files found" root

Ifne verfügt über eine Option -n, die sein Verhalten umkehrt: Mit dieser Option startet es das angegebene Programm nur, wenn die Standardeingabe leer ist.

Lckdo

In vielen Situationen, in denen automatisierte Prozesse laufen, darf nur eine Instanz eines Programms laufen. Verzögert sich ein Prozess, weil unerwartet viele Daten zum Bearbeiten anstehen, kommt es unter Umständen zu Konflikten oder Datenverlust. Falls Cron entsprechende Jobs in zu kurzen Abständen anstößt, entsteht eine Schleife: Die erste Instanz hat ihre Aufgabe noch nicht erledigt, während schon die nächste die noch nicht abgeschlossene Datenbank überschreibt.

In solchen Situationen weichen Programmierer normalerweise auf Lock-Dateien aus. Bevor die eigentliche Arbeit beginnt, lassen Sie den Task eine (oft leere) Datei anlegen, normalerweise unter /var/lock/. Nach Beendigung seiner Aufgabe löscht der Task diese wieder. Existiert die Datei schon, setzt die Software ihre Arbeit aus. Manchmal enthält die Lock-Datei zusätzlich die ID des Prozesses, der sie angelegt hat.

Ein solcher Lock-Mechanismus lässt sich relativ unkompliziert implementieren, selbst in Skripten. Allerdings macht lckdo das Leben noch etwas leichter. Sie verwenden den Befehl dabei wie Nice oder Nohup (Listing 3). Über Optionen steuern Sie das genaue Verhalten des Tools.

$ lckdo [Option] Lock-File Programm

Besteht eine Lock-Datei, so meldet das Tool dies (Listing 4, erste Zeile). Außerdem dürfen Anwender nicht unter allen Umständen Lock-Files unter /var/lock/ erzeugen – das meldet das Programm ebenfalls (Listing 4, letzte Zeile). In diesem Fall weichen Sie auf ein anderes Verzeichnis aus, etwa das Home-Verzeichnis.

lckdo: lockfile `~/tst' is already locked
lckdo: unable to open `/var/lock/tst': Permission denied

Lckdo löscht die erzeugten Lock-Files wieder, nachdem sich das übergebene Programm beendet hat. Allerdings enthalten die Lock-Files keine Prozess-ID – das würde es erleichtern, hängende Programme von Hand zu terminieren.

Im Paket util-linux gibt es zudem mit Flock ein Programm mit ähnlicher Funktion, aber etwas anderen Optionen. Die Lckdo-Manpage informiert daher darüber, dass es das Tool in künftigen Versionen der Moreutils vermutlich nicht mehr gibt.

Parallel-moreutils

Um Programme mehrfach (oft mit unterschiedlichen Argumenten) parallel zu starten, gibt es verschiedene Tools, die alle parallel oder ähnlich heißen. Die Moreutils enthalten mit parallel-moreutils ebenfalls eine Variante. Die simple Syntax ähnelt der anderer Implementationen (Listing 5, Zeile 1).

$ parallel-moreutils Optionen -- Programm mit Argumenten
$ parallel-moreutils Optionen Programm -- Argumente
$ parallel-moreutils ufraw --out-path=fertig/ ... -- *raw

Darüber hinaus unterstützt das Tool eine zweite Syntax-Variante (Listing 5, Zeile 2), die durchaus ebenfalls ihre Berechtigung hat, wie das Beispiel aus der letzten Zeile von Listing 5 zeigt. Dort trennt der doppelte Bindestrich die durch das Muster definierten RAW-Files. Da die Software voreingestellt für jeden vorhanden CPU-Kern einen Prozess startet, beschleunigt dies das Bearbeiten in vielen Fällen deutlich. Allerdings sinkt die Verarbeitungszeit nicht linear mit der Anzahl der Kerne, da die Ein- und Ausgaben einen Flaschenhals darstellen.

Über die Option -j Anzahl steuern Sie die Anzahl der gestarteten parallelen Prozesse. Vernünftigerweise belassen Sie Anzahl unterhalb der Anzahl der Prozessorkerne, Sie dürfen das Argument tatsächlich aber größer wählen. Mit -l Dezimalzahl definieren Sie die maximale Load (ein Maß für die Systemlast), bis zu der die Parallel-moreutils weitere Prozesse startet. Nach dem Überschreiten dieses Grenzwerts setzt es den Start aus, bis die Last wieder sinkt. Das erfolgt ähnlich wie bei Loadwatch [2].

Um Parallel-moreutils möglichst universell einsetzen zu können, besteht die Möglichkeit, die mit dem Kommando ausgeführten Befehle zu manipulieren. Dazu stehen zwei Optionen bereit.

Mit -i organisieren Sie den Befehl um. Voreingestellt fügen Sie die durch ein Argument erzeugten Bestandteile – etwa die durch *.raw generierten Dateinamen – an das Ende der Befehlszeile an. Durch -i ersetzt Parallel-moreutils jedes Auftreten von {} in der Befehlszeile durch den mit dem Argument erzeugten Text (also etwa die Dateinamen).

Mit -n Zahl definieren Sie die Anzahl der Argumente, die das Programm in einem Schritt in die Befehlszeile übernimmt und an das Programm übergibt. Die Option dürfen Sie nicht in Kombination mit -i verwenden.

Zrun

Werkzeuge wie Parallel-moreutils erzeugen in der Praxis ungewöhnliche Effekte, insbesondere bei etwas komplexeren Befehlen. Der kleine Befehl zrun dagegen lässt sich aufgrund seiner simplen Syntax (Listing 6) sehr einfach verstehen und anwenden. Das Programm dekomprimiert die übergebenen Archive on-the-fly, was Plattenplatz spart. In der aktuellen Version arbeitet es mit Dateien in den Formaten GZIP, BZIP2, Z, XZ, LZMA und LZO zusammen.

$ zrun Programm mit Argumenten komprimierte Daten

Einen typischen Einsatzfall stellt das Arbeiten mit komprimierten Textdateien dar. Der Versuch, eine solche mit einem Editor zu öffnen, führt zu einem unbrauchbaren Ergebnis; mit Zrun sieht das gleich ganz anders aus (Abbildung 1). In der Titelzeile des Editors sehen Sie, dass Zrun eine temporäre, unkomprimierte Datei erzeugt hat, die dann im Editor landet.

Abbildung 1: Mit via Zrun on-the-fly dekomprimierten Daten sieht das Ergebnis im Editor so aus wie erwartet.

Da Zrun die entpackte Datei nach dem Beenden wieder löscht, gehen damit alle Änderungen verloren – es sei denn, Sie sichern das Ergebnis unter einem anderen Namen. So entsteht eine neue, veränderte, aber unkomprimierte Version des Originals. Sie erneut zu komprimieren, bleibt Ihnen überlassen. Gute Editoren stellen da die bessere Wahl dar: Sie können komprimierte Dateien sowohl lesen als auch schreiben.

Zrun hat ein weiteres Feature: Erzeugen Sie einen Link zu diesem Programm, in der Form zBinary, so startet dieser Link als zrun Binary. Mit ln -s /bin/zrun /tmp/znano erzeugen Sie den temporären Befehl /tmp/znano, und znano Datei wirkt dann genau wie zrun nano Datei.

Combine

Eine zweite Gruppe von Befehlen der Moreutils bearbeitet oder testet Dateien. Diese recht unterschiedlichen Programme beziehen sich zum Teil explizit auf Textdateien. Das verwundert nicht, da diese Dateien seit vielen Jahren für zahlreiche Aufgaben im Einsatz sind. Neben Konfigurationsdateien liegen viele Log-Files als “Plaintext” vor.

Beim Umgang mit Textdateien erweisen sich zwar die traditionellen Unix-Tools als sehr mächtig, die es alle auch unter Linux gibt. Für einige spezielle Aufgaben braucht es dann aber doch erhebliche Klimmzüge. Dazu gehört das logische Verknüpfen von Textdateien, wie es das Kommando combine ermöglicht.

Es kombiniert alle Zeilen zweier Dateien über einen logischen Operator – zur Auswahl stehen AND (logisches Und), OR (logisches Oder), NOT (Nicht) und XOR (Verschieden) – und zeigt das Ergebnis an. Beim Operator AND erscheinen dann nur die Zeilen, die sowohl in der ersten Datei als auch in der zweiten Datei vorliegen. Der Inhalt der Textzeilen ist für die Combine ohne Belang, es wertet ihn aber gänzlich aus.

Die Syntax des Befehls zeigt Listing 7. Sie dürfen jede der Dateien durch die Standardeingabe ersetzen, die Sie durch - symbolisieren. Die eingesetzten Operatoren erkennt das Programm unabhängig von der Schreibweise.

$ combine Datei Operator Datei

In der Tabelle “Testdateien” sehen Sie den Inhalt der für das Beispiel aus Listing 8 verwendeten Test-Files. Im Listing lassen wir den Operator XOR alle Zeilen aus den Dateien A und B herausfiltern, die nicht identisch sind.

$ combine A xor B
a2
a3
b2
b3
b5

Die Files A und B verfügen über eine gemeinsame und ansonsten komplett unterschiedliche Zeilen. Letztere filtert das Tool mittels XOR heraus. Bemerkenswert ist dabei, dass die Datei B um eine Zeile länger als A ist – trotzdem erscheint c5 in der Ausgabe. Das Tool bearbeitet also selbst leere Zeilen.

Isutf8

Auf aktuellen Linux-Systemen liegen Textdateien normalerweise als UTF-8-kodierte Daten vor. Ist das nicht der Fall, treten beim Bearbeiten unter Umständen unerwünschte Effekte auf. Es bietet sich daher an, zunächst zu überprüfen, ob die Kodierung stimmt. Mittels isutf8 aus den Moreutils testen Sie Dateien, ob sie den Anforderungen von UTF-8 genügen. Ist die Datei konform kodiert, erfolgt keine Ausgabe; falls nicht, zeigt die Software das an (Listing 9).

$ isutf8 1bicec.tmp
1bicec.tmp: line 1, char 15, byte 14: Expecting bytes in the following ranges: 00..7F C2..F4.

Das eigentliche Auswerten erfolgt aber wie üblich durch den Rückgabewert des Befehls. Bei UTF-8-Dateien gibt das Tool null zurück. Ein paar Optionen modifizieren das Verhalten von Isutf8: So unterdrückt -q (--quiet) die Meldung, dass eine Datei nicht UTF-8-konform ausfällt. Mit -l (--list) bewirken Sie, dass die Software nur die Namen von nicht konformen Dateien ausgibt. Über -i (--invert) zeigt das Programm nur noch UTF-8-konforme Dateien an.

Zeitstempel

Bei Zeitmarken handelt es sich um kurze Strings mit der aktuellen Zeit. Sie kommen etwa zum Einsatz, um Einträge in Log-Dateien zu datieren. Die Moreutils enthalten mit ts einen Befehl, der STDOUT-Ausgaben solche Timestamps voranstellt (Listing 10). Auf diese Weise lassen sich etwa die Abläufe in Skripten zeitlich nachverfolgen.

$ cat tstest.sh
echo "Jetzt geht's aber los."
sleep 3
echo "Drei Sekunden später."
sleep 2
echo "Fünf Sekunden vorbei."
$ bash tstest.sh | ts
Nov 28 14:23:15 Jetzt geht's aber los.
Nov 28 14:23:18 Drei Sekunden später.
Nov 28 14:23:20 Fünf Sekunden vorbei.
$ bash tstest.sh | ts "%c"
Mo 28 Nov 2016 14:30:35 CET Jetzt geht's aber los.
Mo 28 Nov 2016 14:30:38 CET Drei Sekunden später.
Mo 28 Nov 2016 14:30:40 CET Fünf Sekunden vorbei.
$ bash tstest.sh | ts -s
00:00:00 Jetzt geht's aber los.
00:00:03 Drei Sekunden später.
00:00:05 Fünf Sekunden vorbei.
$ bash tstest.sh | ts -i
00:00:00 Jetzt geht's aber los.
00:00:03 Drei Sekunden später.
00:00:02 Fünf Sekunden vorbei.

Die Zeitmarken konstruiert das Tool mit der Funktion strftime, wie sie auch im Kommando date zum Einsatz kommt. Es ist folglich möglich, die Ausgabe über Platzhalter anzupassen. Dafür nutzen Sie kurze Zeichenketten in der Form %s oder %D, die jeweils für bestimmte Aspekte stehen. Mit man 3 strftime erfahren Sie mehr über die Möglichkeiten; die Tabelle “Platzhalter” fasst die wichtigsten Zeichenketten zusammen. Voreingestellt verwendet ts das Format "%b %d %H:%M:%S" für die Ausgabe, ein anderes geben Sie zwischen doppelten Hochkommata als letztes Argument oder als Argument der Option -s an.

Einige weitere Optionen steuern das Verhalten des Tools: Über -r wandelt die Software vorhandene Zeitmarken in relative Angaben um. Das funktionierte im Test aber nur mit Marken im voreingestellten Format. Mit -i berechnet die Software die Stempel als Differenz zur zuletzt gesetzten Zeitmarke.

Vidir

Manche Situationen erfordern es, die Ausgaben etwa von Ls oder Find manuell zu verändern. Meistens dient das dem Vorbereiten weitergehender Aktionen, etwa dem Erstellen eines Archivs, oder zum direkten Bearbeiten von Dateien, etwa dem gezielten Löschen.

Mit vidir stellen die Moreutils einen speziellen Befehl bereit, der genau das macht. Er lädt den Inhalt eines Verzeichnisses (voreingestellt das aktuelle Verzeichnis) oder genauer spezifizierte Teile davon (vidir *.jpg) in den voreingestellten Editor. Diesen Editor definiert die Umgebungsvariable $EDITOR oder alternativ $VISUAL. Um Suchergebnisse auf diese Weise zu bearbeiten, pipen Sie die Ergebnisse von Find in Vidir. So bearbeiten Sie mit find | vidir - beispielsweise auch Unterverzeichnisse mit.

Das vom Programm verwendete Format verwundert zunächst etwas: Jede Zeile beginnt mit einer Zeilennummer. Anhand dieser stellt Vidir nach dem Beenden des Editors fest, welche Dateien es entfernen soll: Löschen Sie etwa Zeile 18 aus der temporär angelegten Datei im Editor und schließen ihn dann, so versucht Vidir die in Zeile 18 enthaltene Datei ebenfalls zu löschen. Das analoge Anlegen von Dateien funktioniert allerdings nicht. Dafür dürfen Sie aber eine vorhandene Datei umbenennen, indem Sie deren Namen in der Datei ändern. Durch Vertauschen von Zeilennummern wechseln Sie Dateinamen.

Die Leistungsfähigkeit von Vidir hängt im Wesentlichen von der des verwendeten Editors ab. Mit Emacs beispielsweise können Sie komplexe, regelbasierte Ersetzungen oder Löschungen vornehmen. Allerdings stellt gerade dieser Editor eigene, sehr leistungsfähige Schnittstellen zum Dateisystem bereit.

Mispipe

Pipelines zählen zu den mächtigsten Konstrukten in Shells. Tatsächlich gibt es kaum eine effektivere Möglichkeit, Daten zwischen unterschiedlichen Prozessen weiterzugeben. Entsprechend oft kommen Pipes zum Einsatz. Voreingestellt werten allerdings viele Shells lediglich den Rückgabewert des letzten Befehls einer Pipe aus. Schlägt der Aufruf eines der früher in der Pipe eingesetzten Befehle fehl, bemerkt dies die Shell nicht oder reagiert zumindest nicht adäquat darauf, etwa im Kurzschlusstest (“short circuit test”, ||, &&, …).

Viele Pipes bestehen nur aus zwei Befehlen. Der erste erhebt die Daten, der zweite verarbeitet sie. Hier wäre es also wichtig, zu reagieren, wenn im ersten Schritt ein Fehler auftrat. Für diese Situation ist mispipe gedacht: Es wertet die Rückgabe des ersten Befehls aus.

Das Beispiel aus Listing 11 erzeugt immer dann, wenn keine Datei vorhanden ist, auf die das Muster fehlt* passt, ein Ooops als Ausgabe. Dies geschieht, weil ls einen Rückgabewert von 2 erzeugt hat. Der Rückgabewert des Grep-Befehls spielt dabei keine Rolle. Findet der Befehl ls passende Dateien, filtert Grep alle Zeilen heraus, in denen eine 1 auftritt.

$ mispipe "ls -l fehlt*" "grep 1" || echo Ooops

Pee

Ebenfalls für den Einsatz in Pipes wurde pee entwickelt, ein Pendant zum dateiorientierten Befehl tee (Listing 12). Während Tee Ausgaben eines Skripts oder Programms auf zwei Dateien und STDOUT ausgibt, verteilt Pee sie auf zwei Pipes, unterlässt jedoch die Ausgabe auf STDOUT.

$ ./skript.sh | tee ausgabe1.txt ausgabe2.txt
$ ./skript.sh | pee "grep Muster" "gzip -c > ausgabe.gz"

Vipe

Das Programm Vipe erlaubt es, Editoren in Pipes zu verwenden (Listing 13). Das klingt zunächst nur begrenzt sinnig, bestehen Pipes doch aus der direkten Verbindung des Kanals STDOUT des ersten Befehls mit der Standardeingabe des zweiten. Manchmal ist es aber sinnvoll, die Daten vor dem Weiterverarbeiten zu editieren, um sich ein Speichern zwischendurch zu sparen. Vipe liest allerdings zunächst die gesamte Datenmenge ein, arbeitet dann auf den Daten und leitet diese nach dem Beenden des Editors weiter. Wie Vidir wertet auch Vipe die Variablen EDITOR und VISUAL aus, um den Editor zu bestimmen.

$ man less | vipe | cat
LUTHER(1)        General Commands Manual        LUTHER(1)
NAME
       luther - opposite of pope
COPYRIGHT
       Copyright (C) 1517-2016 by the Lutheriden
AUTHOR
       Faked 2016 by Joerg Luther <jluther@linux-user.de>
                 Version 499: 28 Nov 2016        LUTHER(1)

Sponge

Ebenfalls für den Einsatz in Pipes eignet sich der Befehl sponge (engl.: Schwamm). Zwar gibt es in der Shell die Möglichkeit, Daten jederzeit durch Umleiten in eine Datei zu überführen – dort landen die Daten dann kontinuierlich (“atomic”) und über die gesamte Laufzeit der Befehlszeile beziehungsweise Pipe.

Sponge macht das anders: Es sammelt die Daten zunächst intern und überführt sie erst am Ende in eine Datei. Das erlaubt unter anderem das Verwenden derselben Datei für Ein- und Ausgaben, was normalerweise nicht klappt (Listing 14).

$ cat file
7
5
3
$ sort -u file | sponge file
$ cat file
3
5
7
$ sort -r file | sponge -a file
$ cat file
3
5
7
7
5
3

Fehlt die Angabe der Ausgabedatei, verwendet das Programm die Standardausgabe. Existiert die Ausgabedatei, so behält sie ihre Permissions bei. Die Option -a hängt die Ausgabe an den Inhalt der Datei.

Fehlerbehandlung

Auf Linux-Systemen geben eine Reihe von Werkzeugen wie Strace recht kryptisch anmutenden Fehlermeldungen aus. Normalerweise schlagen Sie diese symbolischen Namen dann mittels man 3 Fehlernummer nach und hoffen, dass die Beschreibung weiterhilft.

Einfacher gelingt das Zuordnen von Namen und passenden Nummern mittels errno (Listing 15). Mit der Option -s (--search) können Sie die Fehlermeldungen schreibweisenunabhängig nach bestimmten Begriffen durchstöbern; mit der Option -S durchsucht das Programm zusätzlich alle installierten Manpages anderer Sprachen, was gelegentlich weitere Treffer zutage fördert. Eine Suche nach Fehlernummern gelingt auf diesem Weg nicht – dazu lassen Sie Errno über den Parameter -l alle Fehlernamen ausgeben und suchen in der Liste per Grep.

$ errno eio
EIO 5 Eingabe-/Ausgabefehler
$ errno 5
EIO 5 Eingabe-/Ausgabefehler
$ errno -s Ausgabefehler
EIO 5 Eingabe-/Ausgabefehler
EREMOTEIO 121 Ein-/Ausgabefehler der Gegenstelle (remote)
$ errno -l | grep 121
EREMOTEIO 121 Ein-/Ausgabefehler der Gegenstelle (remote)

Netzwerkschnittstelle

Der Befehl ifdata prüft, ob ein bestimmtes Netzwerkinterface existiert und aktiv ist. Darüber hinaus lassen sich statistische Daten zu der Netzwerkschnittstelle abfragen. Die simple Syntax, die dem Schema ifdata Option(en)Interface folgt, lässt schon erkennen, dass der Befehl hauptsächlich für den Einsatz in Skripten gedacht ist. Die wichtigsten Optionen von Ifdata fasst die Tabelle “Ifdata: Wichtige Optionen” zusammen.

Fazit

Neben einigen wirklich rundum hilfreichen Werkzeugen wie Pee oder Ts bieten die Moreutils einige sehr spezielle Tools für unterschiedlichste Aufgaben an. Viele Anwender können darauf vermutlich gut verzichten; wer aber häufig Skripte schreibt, der weiß die nützlichen Abkürzungen schnell zu schätzen. Um solche Skripte aber weiterzugeben, müssen auch auf dem Zielsystem die Moreutils vorliegen, was sicher nicht immer gegeben ist.