Regex……

Regular Expressions (kurz: regex) sind einzelne Zeichen oder Zeichenketten mit denen man dazu passende Zeichenfolgen in einer Datei oder der Ausgabe eines Programms suchen kann.

Regex lassen sich mit Unixoiden Tools wie grep oder egrep nutzen, oder in Programmiersprachen die das unterstützen, zu den letzteren zählt u.a. Java.

ls * oder dir *.txt dürfte zu den verbreitetsten Anwendungen von regex’en zählen. Das „*“ – Zeichen bzw. die Zeichenkette „*.txt“ bilden die Suchvorschrift nach der die passende Zeichenketten ausgegeben werden.

Grundlagen
Alle hier vorgestellten Beispiele habe ich unter Mac OS X 10.9.5 im Terminal getestet.

Das Tool grep unterstützt unter Mac OS nicht den vollen Umfang der regex. Ich empfehle deshalb egrep zu benutzen, damit können auch umfangreichere Ausdrücke verarbeitet werden.

Wenn etwas verlinkt ist, dann war der letzte Aufruf = Stand dieses Posts.

Beispiele
Kurz und schlank, eine Erklärung folgt irgendwann….

Grundlegender Syntax:

egrep "regex" suchtext.txt

Telefonnummern finden:

egrep "0[0-9]{3}-[0-9]{3,15}" testFile.txt

Findet Telefonnummern, ohne internationale Vorwahl.

Shell Quotes

Meta- Zeichen Unixoider Systeme sind unter Anderem das ‚*‘ oder ‚?‘- Zeichen, beispielsweise im Zusammenspiel mit dem ‚ls‘ Kommando. 

Möchte man solche Zeichen aber in der Ausgabe mit ‚echo‘ oder ‚printf‘ zur Ausgabe benutzen, dann muss man das dem Interpreter der Shell sagen. Das geht indem man dem Zeichen entweder ein ‚\‘ voranstellt oder es in die ‚ bzw. “ Zeichen einschließt:

echo \*

echo ‚*‘

echo „*“

Diese Technik wird als Quoting bezeichnet. Alle drei der oben gezeigten Methoden machen im Prinzip das Selbe. Der Unterschied ist der:

\
Ist die stärkste Form des Quoting.  Für einzelne Zeichen.

 


Strong Quoting
Alle Zeichen werden ausgegeben, auch das ‚$‘. Das heist, Inhalte von Variablen werden nicht berücksichtigt: echo ‚$Hallo‘ hat ‚$Hallo‘ zum Ergebnis.

 


Weak Quoting
Wenn man Meta- Zeichen ausgeben möchte, aber die Inhalte von Variablen und Kommandos (zwischen den ` Zeichen) berücksichtigen möchte, dann sollte man diese Form benutzen: echo „Hallo das ist der Inhalt von $i“. Gibt den angegebenen Text und den Inhalt der Variablen ‚i‘ aus. wenn Sie das so machen: echo ‚Hallo das ist der Inhalt von $i‘ dann ist das Ergebnis: Hallo das ist der Inhalt von $i.

Eine spezielle Bedeutung dabei hat das ` – Zeichen. Es wird nicht als Quote verstanden, sondern als  Kommando- Ersatz:

echo Sie sind im Verzeichnis: `ls`

oder etwa:

echo Heute ist der `date`

 

 

Strings ändern, Unixoide Tools

Zur Verarbeitung von Zeichenketten (Strings) stellen Unixoide System traditionell einige Werkzeuge zur Verfügung. Ich beschreibe hier ein paar davon im Hinblick auf deren Einsatz- Zweck und die jeweiligen Grenzen. Ich bleibe dabei oberflächlich, das geschriebene soll für jedes der Werkzeuge einen Schnelleinstieg möglich machen und ein Gefühl für den Syntax vermitteln.

Grundlagen

Wenn links wiedergegeben werden, dann entspricht das Datum des letzten Aufrufs dem jeweiligen Bearbeitungsstand dieses Blogeintrages.

Alle Beispiele wurden auf einem Mac- Book Pro unter Mac OS X getestet.

Grundsätzlich sind die hier vorgestellten Werkzeuge dazu da, Zeichenketten zu verändern. Andere wichtige, hier nicht behandelte Werkzeuge dienen lediglich der Auswertung von Zeichenketten. Die wichtigsten sind: grep (oft zusammen mit Regulären Ausdrücken: —regexp) und find.

Alle Werkzeuge lesen Zeichen aus einem Eingabestrom (einer Datei) und geben das Ergebniss auf stdout aus. arbeiten nahtlos mit Umleitungen „>“ , „>>“ oder Pipes „|“ zusammen.

tr

Steht für Translate. Eignet sich immer dann, wenn man einzelne Zeichen ändern möchte. Man kann zwar mehr als ein zu änderndes oder zu löschendes Zeichen angeben, die werden aber nicht als zusammenhängendes Wort interpretiert, sondern bleiben einzelne Buchstaben

tr 'a' 'b' < Datei.txt

Wandelt alle „a“ aus der Eingabe Datei in ein „b“ in der Ausgabe.

tr -d 'a' < Datei.txt

„-d“ führt dazu dass alle „a“ gelöscht werden.

tr 'abcd'  'jklm' < Datei.txt

Wenn mehr als ein Zeichen angegeben wird , dann schreibt man die in Anführungszeichen. Hier werden der Reihe nach, alle Buchstaben im ersten Argument durch die Buchstaben im zweiten ersetzt.

Als Bereichs Kennzeichnung darf „-“ benutzt werden: „a-z“ meint alle Zeichen zwischen „a“ und „z“.

Spezielle Zeichen müssen mit „\“ escaped werden: „\n“, „\t“, „\\“ usw.

sed

Abkürzung für Stream Editor. Zwingend, wenn man mehr als ein Zeichen manipulieren möchte. Erlaubt Reguläre Ausdrücke.

sed 's/Hallo/hi/g' test.txt > changed.txt

Ersetz alle „Hallo“ in „test.txt“ nach „hi“ und schreibt das Ergebnis in die Datei „changed.txt“. Das „s“ vor dem ersten „/“ heist ’substitute‘ das „g“ nach dem letzten „/“ heist „globally“ und meint das alle in „test.txt“ vorkommenden „Hallo“ ersetz werden sollen. Wenn man das „g“ weglässt, wird jeweils nur das erste in einer Zeile vorkommende „Hallo“ ersetzt.

awk

Mächtig, Vorfahre von Perl. Wie sed für die Manipulation längerer Zeichenketten geeignet. Wichtigstes Merkmal: Arbeiten Zeilen und Spaltenorientiert. Das heist, eine Zeile wird aus der Eingabe bis „/n“ gelesen. Die Leerzeichen werden als Trenner zwischen den Spalten interpretiert. Die Spalten lassen sich mit „$n“ auslesen.

GIT- Schnellstart

Wie geht GIT, kurz und knapp zum Schnelleinstieg.

Abstrakt

Zu GIT gibt es im Netz eine Fülle an detaillierten Tutorials und Guides zum Schnelleinstieg. In diesem Artikel sind meine eigenen Erfahrungen dazu wiedergegeben, praxisorientiert mit den Dingen die ich im Moment nützlich finde und brauche.

Grundlagen

Alle Links in diesem Artikel wurden am 20.11.2017 zuletzt abgerufen. Wenn Sie GIT installiert haben, dann gehen Sie in die Konsole ihres Systems und geben ein:

git –version

Vergleichen Sie die Ausgabe mit der von mir genutzten Version:

git version 1.8.5.2 (Apple Git-48)

Wie man sehen kann, ich habe einen Macintosh. Sollte irgendwo hier etwas anderes zutreffen, erwähne ich es.

Wenn ich mich auf Android Studio beziehe, dann meine ich damit die Version 2.3.3

Neues repository anlegen

Im Verzeichnis, in dem wir künftig arbeiten wollen geben wir zunächst ein:

git init

Damit hätten wir die GIT- Kontrolle für diese Verzeichnis eingeschaltet, oder, in der GIT- Terminologie: Das Verzeichnis enthält nun ein GIT- Repository. Wenn wir nun eingeben:

git status

Dann können zwei Dinge passieren. Erstens, das Verzeichnis entält ein GIT repositiory:

Initial commit

Untracked files:

(use „git add <file>…“ to include in what will be committed)

Hallo.class

Hallo.java

nothing added to commit but untracked files present (use „git add“ to track)

Zweitens: Das aktuelle Verzeichnis, oder eines der „Eltern“ davon enthält kein GIT- Repository:

fatal: Not a git repository (or any of the parent directories): .git

Die Datei .gitignore

Wie man oben sehen konnte, in dem Verzeichnis, in dem die GIT- Kontrolle aktiviert wurde, sind Dateien enthalten, die nicht überwacht werden (Untracked Files) . Das sind normalerweise alle Dateien im Verzeichnis und allen Unterverzeichnissen, wenn man ein neues GIT- Repository angelegt hat.

Bevor man nun Dateien zur Überwachung anmeldet, sollte man sich überlegen, bei welchen Dateien das überhaupt Sinn macht. Dafür ist die Datei .gitignore zuständig. Dort kann man Dateien, oder zu Datei- und Ordnenamen passende Muster angeben, die ignoriert werden sollen. Diese Dateien werden beim synchronisieren mit einem remote repository nicht hochgeladen.

Normalerweise sollte man Ausführbare Dateien (Beispielsweise Android *.APK) die üblicherweise viel Speicherplatz benötigen nicht überwachen. Letzteres wäre nun nicht unbedingt ein Nachteil, aber, wenn man sein repository mit einem remote repository synchronisiert kann das sehr zeitaufwändig werden und es  unötig aufblasen. Davon abgesehen ist GIT ja dazu da source code zu teilen. Die Ausführbare Datei sollte dann daraus auf dem lokalen Rechner erzeugt werden.

Die Datei .gitignore sollte man füllen, bevor man Dateien zur Überwachung hinzufügt, weil, einmal überwachte Dateien können nicht mehr ignoriert werden!

Dateien zur Überwachung (tracking) hinzufügen

GIT ist normalerweise sehr freundlich ist und sagt, was zu tun ist. Oben ist zu lesen: Das man eine Datei deren Änderungsstand man überwacht und dokumentiert haben möchten mit ‚add‘ anmelden muss:

git add <datei>

Wenn man das gemacht hat, meldet GIT nach einer erneuter Statusabfrage das:

Changes to be committed:

(use „git rm –cached <file>…“ to unstage)

new file:   Hallo.java

Untracked files:

(use „git add <file>…“ to include in what will be committed)

Hallo.class

Die Datei ‚Hallo.java‘ ist angemeldet. In GIT heist das, dass sich diese Datei in der sogenannten Staging Area befindet. GIT sagt uns auch gleich was zu tun ist, wenn man die Datei nicht mehr dort haben möchte (‚rm –cached <Datei>).

Anmerkung: Man muss  nicht jede Datei nach dem oben gezeigten Muster manuell hinzufügen. Wenn man nur die geänderten Dateien berücksichtigen möchten, dann geht man so vor:

git add .

Dateien die gelöscht wurden sind im lokalen Repository natürlich nicht mehr enthalten. Wenn man das aber dann mit einem remote Repository synchronisiert, dann werden diese Dateien dort nicht gelöscht. Um das zu erreichen muss man im lokalen Repository folgendes machen:

git add –all .

Damit werden die lokal gelöschten Dateien nach dem git push origin master Befehl auch auf dem remote Repository gelöscht.

Alle Dateien in der Staging Area werden nach dem „commit’en“ mit ihren Änderungen protokolliert. Das Schaut dann so aus:

git commit

Anmerkung: Für Git zählen geänderte Dateinamen nicht zu einer Protokoll- pflichtigen Änderung. GIT prüft nur, ob Inhalte geändert wurden. So lange man in einem lokalen Repository arbeitet, merkt man das nicht. Wenn man aber das lokale mit einem remote Repository synchronisiert (git push origin master), Dann werden diese Änderungen nicht synchronisiert!

Wenn man aber möchte, dass auch Dateien deren Namen geändert wurden auch im remote repository umbenannt werden, dann kann man das so machen: Im Lokalen Repository die Dateien umbenennen, ausschneiden und wieder einfügen. Dann commiten.

Ich habe mir in der GIT- Konfiguration den Emacs als Standard Editor eingestellt. Wenn Sie das auch gemacht haben (irgend ein anderer, wenn es sein muss auch Vi, geht auch) dann startet der und Sie können eine Commit Message eingeben. Nach dem Verlassen des Editors, ist der Commit erledigt und GIT antwortet:

[master (root-commit) 258ae40] Erste Version

1 file changed, 12 insertions(+)

create mode 100644 Hallo.java

Die erste Zeile wiederholt nochmals ihre Commit Message. Interessant ist das, was davor steht: master…….

In GIT können Sie parallel zu ihren jeweiligen Datei- Versionen, parallele Arbeitstände bearbeiten. Diese Parallel Versionen werden in GIT Branches genannt. Es lassen sich beliebige viele Branches anlegen und zu jedem Zeitpunkt wieder vereinen.

Die Ausgabe oben sagt uns, das wir die Datei ‚Hallo.java‘ im standardmäßig angelegten Branch ‚Master‘ commitet haben.

Branches

Einen neuen Branch können Sie mit:

git branch neuerBranch

Sie befinden Sich danach immer noch in ihrem Branch ‚Master‘. Sie wechseln mit:

git checkout neuerBranch

M Hallo.java

Switched to branch ’neuerBranch‘

Dieser Branch ist jungfräulich und Sie müssen die Eingangs beschrieben Schritte zum commiten wiederholen. Alle Änderungen werden nun aber nur in ihrem ’neuerBranch‘ protokoliert. Das betrifft auch jede Datei die Sie ändern. Wenn Sie in einen anderen Branch wechseln, dann finden Sie dort den jeweilig anderen Arbeitsstand wieder. Das heist: Sie haben jetzt zwei Dateien die Sie unabhängig voneinander testen können.

Wichtig ist: Bevor Sie mit ‚checkout‘ zu einem anderen Branch wechseln, müssen Sie die geänderten Dateien mit ‚git add‘ auf die Staging Area legen und dann commiten.

Um eine Übersicht über alle Branches zu bekommen geben Sie ein:

git branch

master

* neuerBranch

Der aktive ist mit einem ‚*‘ markiert.

Wenn Sie die Änderungen zusammenführen möchten, dann machen Sie das So:

git merge master neuerBranch

Updating 258ae40..d92b0fa

Fast-forward

Hallo.java | 4 +++-

1 file changed, 3 insertions(+), 1 deletion(-)

Wenn Sie das jetzt nocheinmal machen, dann passiert folgendes:

git merge master neuerBranch

Already up-to-date.

Das heist, beide Branche’s sind synchron.