In Dateien eines Verzeichnisbaums wollen wir eine mehrzeilige Ersetzung vornehmen. Unter Nutzung von Perl geht dies mit einem Einzeiler:

$ find DIR ... | xargs perl -0777 -p -i -E 's/REGEX/REPLACEMENT/gms'

Hierbei ist REGEX ein Regulärer Ausdruck, der Text über mehreren Zeilen matchen kann. Wie funktioniert der Aufruf?

Perl verarbeitet die Dateien, die von xargs(1) als Argumente übergeben werden, und behandelt sie gemäß den angegebenen Optionen:

-0777

Kein Input-Separator, d.h. Perl liest die jeweilige Datei komplett ein statt sie zeilenweise zu verarbeiten. Dadurch wirkt der Perl-Code, siehe Option -E CODE, nicht auf eine einzelne Zeile, sondern auf den gesamten Dateiinhalt.

-p

Perl iteriert über die Dateien, die als Argumente angegeben sind, und gibt den Dateiinhalt jeweils nach Manipulation durch den Perl-Code CODE mit print aus.

-i

Die Ausgabe mit print ersetzt den Inhalt der ursprünglichen Datei (Bearbeitung "in place"). Wird die Option -i mit einem Wert ergänzt, z.B. -i.orig, bleibt die Originaldatei mit der Endung .orig erhalten. Auf diesem Weg kann Code CODE gefahrlos getestet werden.

-E CODE

Der Perl-Code, der auf den Inhalt der Datei angewandt wird. Dieser kann beliebige Manipulationen vornehmen. Wir führen oben ein einzelnes Substitute s/// aus, mit den Optionen g (alle Fundstellen werden ersetzt), m (^ uns $ matchen Zeilenanfang und Zeilenende), s (der Punkt . matcht auch Zeilenumbrüche). Diese Semantik ist in dem gegebenen Anwendungsfall besonders nützlich.

Beispiel

Entferne im Verzeichnisbaum DIR die Inline-Dokumentation (POD) aus allen .pm-Dateien:

$ find DIR -name '*.pm' | xargs perl -0777 -p -i -E 's/^=[a-z].*?^=cut\n//gms'

Für die Ausführung von Programmen ist es oft notwendig, dass bestimmte Umgebungsvariablen gesetzt sind. Dies kann allgemeine Variablen betreffen, wie z.B. den Suchpfad PATH oder programmspezifische Variablen, wie z.B. ORACLE_HOME.

Die Frage ist, wie man eine Shell-Umgebung aufsetzt, so dass diese möglichst universell nutzbar ist, insbesondere, wenn Programme auch von außerhalb der eigenen interaktiven Sitzung, z.B. via cron, sudo oder ssh ausgeführt werden sollen.

Die Shell (bash, ksh, sh) führt bei jedem Login die nutzerspezifische Datei .profile aus. Werden in dieser Datei alle Environment-Variablen gesetzt (und exportiert), kann die Umgebung leicht in anderen Kontexten genutzt werden. Die Variablen in einer rc-Datei (.bashrc oder .kshrc) zu setzen ist verkehrt, da der Inhalt einer rc-Datei ausschließlich bei interaktiven Sitzungen ausgeführt wird und daher ausschließlich Definitionen enthalten sollte, die für eine Benutzerinteraktion mit der Shell relevant sind (Beispielsweise: Aussehen des Prompt, Aliase, Länge der History, Farben für ls(1), usw.).

TTY-Login, SSH Login

Dies ist der normale Anwendungsfall. Eine Login-Shell wird gestartet und im Zuge dessen .profile ausgeführt.

Ausführung eines Remote-Kommandos per SSH

Das Remote-Kommando ersetzt in diesem Fall die Login-Shell. Wir sorgen mit bash -l dafür, dass die Login-Umgebung hergestellt wird:

$ ssh USER@HOST "bash -lc 'COMMAND'"

X11 Terminal Window Login

Hier ist es wichtig, dass beim Öffnen des Terminals eine Login-Shell ausgeführt wird. Ggf. ist es nötig, hierfür eine Option in den Einstellungen zu aktivieren. In den Einstellungen des Xfce Terminals heißt die Option "Run command as login shell", ist per Default dekativert und sollte aktiviert werden.

sudo

Bei sudo sorgt die Option -i dafür, dass das Kommando an eine Login-Shell übergeben wird:

$ sudo -iu USER COMMAND

cron, eigene crontab

Wie bei der Ausführung eines Remote-Kommandos per ssh sorgen wir mit bash -l dafür, dass die Login-Umgebung vor Ausführung des Kommandos hergestellt wird.

* * * * * bash -lc COMMAND

cron, fremde crontab

Anstelle der bash nutzen wir sudo (wie oben):

* * * * * sudo -iu USER COMMAND

Finde innerhalb des Dateibaums DIR alle Vorkommen des Wortmusters REGEX und gib die Wortliste sortiert aus (GNU grep):

$ grep -oPhr REGEX DIR | sort | uniq

• -o : gib nur den durch REGEX gematchten Textteil aus
• -P : interpretiere REGEX als einen Perl-Regex
• -h : unterdrücke die Ausgabe des Dateinamens
• -r : durchsuche Verzeichnis DIR rekursiv

Soll die Menge der Dateien näher eingeschränkt werden, lässt sich dies durch ein vorgeschaltetes find erreichen (Option -r bei grep entfällt dann):

$ find DIR -type f -print0 | xargs -0 grep -oPh REGEX | sort | uniq

• -print0 ... -0 : Pfade mit Whitespace etc. werden korrekt behandelt

Anwendungsfall

Finde in Dateibaum app mit Perl-Quelltexten die Namen aller verwendeten Klassen, die mit "R1::" beginnen:

$ grep -oPhr 'R1::[:\w]+' app | sort | uniq
R1::AppHome
R1::Array
R1::CheckValue
R1::ClassLoader
R1::Config
R1::Dbms::Database
...

Links

• grep(1) man page

Mitunter möchte man einen Text oder ein Muster global über mehreren Dateien FILE ... ersetzen. Unter Unix/Linux geht das am einfachsten mit sed (GNU):

$ sed -i s/PATTERN/REPLACEMENT/g FILE ...

Das Gleiche, angewendet auf einen Dateibaum DIR:

$ find DIR -type f | xargs sed -i s/PATTERN/REPLACEMENT/g

Perl bietet die sed-Funktionaltät mit einer ähnlich einfachen Kommandozeile:

$ perl -pi -e s/PATTERN/REPLACEMENT/g FILE ...

Der Vorteil von Perl gegenüber sed ist dessen leistungsfähigere Regex-Engine. Bei GNU sed lassen sich mit Option -r "Extended Regular Expressions" einschalten (die eher an Perl Regexes heranreichen).

WICHTIG: Die Ersetzungsoperation wird zeilenweise angewendet, d.h. eine Ersetzung über Zeilengrenzen hinweg ist nicht möglich.

Links

• Sed - An Introduction and Tutorial
• GNU sed Manual
• Perl Regular Expressions

Um einen Unix Epoch-Wert (Sekunden seit 1.1.1970 0 Uhr UTC) mit Shell-Mitteln in eine lesbare Zeitangabe (lokale Zeitzone) zu wandeln, kann man sich des Kommandos date bedienen:

$ date -d @1406546442
Mo 28. Jul 13:20:42 CEST 2014

Dasselbe in einer besser strukturierten Darstellung:

$ date -d @1406546442 '+%F %T %z'
2014-07-28 13:20:42 +0200

Hierbei ist:

%F - Datum
%T - Uhrzeit
%z - Zeitzone als hhmm-Offset

Soll die Ausgabe in einer anderen als der lokalen Zeitzone erfolgen, wird die Environment-Variable TZ entsprechend gesetzt (hier Ausgabe in UTC):

$ TZ=UTC date -d @1406546442 '+%F %T %z'
2014-07-28 11:20:42 +0000

Dasselbe im ISO-8601 Datumsformat (sekundengenau):

$ date -d @1406546442 --iso-8601=seconds
2014-07-28T13:20:42+0200

Die Umkehrung - also die Wandlung einer lesbaren Zeitangabe (der lokalen Zeitzone, wenn keine angegeben ist, hier: MESZ) in Epoch - ist auch möglich:

$ date -d '2014-07-28 13:20:42' +%s
1406546442

Soll die Interpretation in einer anderen Zeitzone als der lokalen Zeitzone erfolgen, kann dies durch Setzen der Environmentvariable TZ erreicht werden:

$ TZ=UTC date -d '2014-07-28 13:20:42' +%s
1406553642 # Differenz zu oben: -7200, also minus 2 Stunden gegenüber MESZ

Der aktuelle Zeitpunkt als Epoch-Wert:

$ date +%s
1406548003

Details siehe date(1) Manpage

Mitunter weiß (oder vermutet) man, dass ein Programm Dateien in einen Bereich des Dateisystems schreibt, aber man weiß nicht genau in welche Verzeichnisse und wie die Dateien heißen.

Dem lässt sich auf den Grund gehen, indem man sich unmittelbar nach Beendigung des Programms die Pfade des betreffenden Dateibaums chronlogisch nach dem letzten Modifikationszeitpunkt sortiert anzeigen lässt. Unter den letzten Pfaden in der Liste sollten die gesuchten Dateien zu finden sein.

Die Unix-Kommandozeile (mit GNU find), die dies leistet, lautet:

$ find DIR -type f -printf '%T+ %p\n' | sort

Hierbei ist DIR das Wurzelverzeichnis des untersuchten Dateibaums. Für jede Datei wird eine Zeile ausgegeben, bestehend aus der mtime in ISO-ähnlicher Darstellung (%T+) und dem Pfad (%p) der Datei.

Details siehe find(1) Manpage

Einer der weniger einleuchtenden Shell-Operatoren ist der Operator >&. Den Klassiker, die Umlenkung von stdout und stderr in eine Datei,

$ cmd >/tmp/file 2>&1

kennt jeder, der häufiger unter Unix unterwegs ist. Es stellt sich dabei aber immer leicht die Frage: Wie war das nochmal? Muss 2>&1 vor der Umlenkung >/tmp/file stehen? Oder dahinter? Gleichgültig ist die Reihenfolge jedenfalls nicht.

Die Beschreibung auf der Bash-Manpage ist recht knapp:

The operator [n]>&word is used to duplicate output file descriptors. If word expands to one or more digits, the file descriptor denoted by n is made to be a copy of that file descriptor. If n is not specified, the standard output (file descriptor 1) is used.

Das heißt, man kann den Operator N>&M als Zuweisung verstehen: Das Ausgabeziel (Terminal, Datei oder Pipe), das seitens des schreibenden Prozesses über Deskriptor M erreicht wird, wird von der Shell (zusätzlich) mit Deskriptor N verbunden. Alles, was der schreibende Prozess auf Desktiptor N schreibt, gelangt somit an das gleiche Ziel wie das, was er auf Deskriptor M schreibt. Liegen mehrere Umlenkungsoperationen vor, werden diese von links nach rechts ausgewertet. Es folgen einige Anwendungsfälle.

Stderr und stdout gemeinsam auf eine Pipe lenken

$ cmd1 2>&1 | cmd2

1. Deskriptor 1 (stdout) von cmd1 wird von der Shell mit der Pipe verbunden (|).

2. Deskriptor 2 (stderr) wird ebenfalls mit der Pipe verbunden (2>&1).

Ergebnis: stdout und stderr gehen auf die Pipe.

Stderr statt stdout auf eine Pipe lenken

$ cmd1 2>&1 >/dev/null | cmd2

1. Deskriptor 1 (stdout) von cmd1 wird von der Shell mit der Pipe verbunden (|).

2. Deskriptor 2 (stderr) wird ebenfalls mit der Pipe verbunden (2>&1).

3. Deskriptor 1 (stdout) wird mit /dev/null verbunden (>/dev/null).

Ergebnis: stderr geht auf die Pipe, stdout geht nach /dev/null.

Stdout und stderr vertauschen

$ cmd 3>&1 1>&2 2>&3 3>&-

1. Deskriptor 3 geht auf das gleiche Ziel wie Deskriptor 1 (3>&1).

2. Deskriptor 1 geht auf das gleiche Ziel wie Deskriptor 2 (1>&2).

3. Deskriptor 2 geht auf das gleiche Ziel wie Deskriptor 3 (2>&3).

4. Gib Deskriptor 3 frei (3>&-).

Ergebnis: stdout und stderr sind vertauscht.

Finde in Dateibaum DIR alle Dateinamen mit Sonderzeichen, also mit Zeichen, die nicht im ASCII-Zeichensatz liegen:

find DIR | perl -ne "print if /[^[:ascii:]]/"

Umlaute und andere Non-ASCII-Zeichen in Dateinamen sind problematisch und sollten vermieden werden, wenn nicht garantiert ist, dass systemweit mit ein und demselben Encoding gearbeitet wird, denn das Encoding eines Dateinamens lässt sich aus diesem nicht herleiten.

Mit der Option -a führt rsync den Abgleich im "Archive Mode" durch, d.h. Symlinks, Devices, Permissions, Ownerschaft usw. werden auf die Zielmaschine transferiert.

Was aber, wenn gewisse Unterschiede erforderlich sind, z.B. die Ownerschaft einiger Dateien verschieden sein muss, weil der Owner oder die Group auf der Zielmaschine anders heißen?

Beispiel: Die Group des HTTP-Servers heißt auf der einen Maschine "www-data" während sie auf der anderen Maschine "apache" heißt. Über die Group bekommt der HTTP-Server Rechte auf bestimmten Dateien eingeräumt, sie muss also passend zur Maschine gesetzt sein.

Solche Differenzen kann rsync nicht auflösen und bietet auch keine Option hierfür. Es lässt sich aber mit einem nachgeschalteten Shell-Skript erreichen, das via ssh auf der Zielmaschine ausgeführt wird:

rsync -avz --delete -e ssh DIR1/ USER@HOST:DIR2
ssh USER@HOST CMD

Wird CMD in DIR1 abgelegt, wird es durch den rsync-Aufruf mit verwaltet, also automatisch auf dem neusten Stand gehalten.

Verzeichnisbaum spiegeln (local => remote)

$ rsync -avz --delete DIR1/ USER@HOST:DIR2

Der trailing Slash bei DIR1/ ist wichtig, da sonst DIR1 in dir DIR2 hineinkopiert wird. Die Verzeichnisse können unterschiedlich heißen.

Bei Angabe der Option -n wird die Ausführung nur simuliert.

Via ssh

$ rsync -e ssh -avz --delete DIR1/ USER@HOST:DIR2

Via ssh mit speziellem Port

$ rsync --rsh='ssh -p port' -avz --delete DIR1/ USER@HOST:DIR2