Die Bash begleitet mich als DevOp (um mal eines der neuen Buzz Words zu bemühen) schon sehr lange. Doch man lernt nie aus. Dieses kleine Snippet entfernt vom Prozedurnamen, der in $0 enthalten ist, den Pfadbestandteil.
#!/bin/bash ME=${0##*/} # Ausgabe mit Pfadangabe echo $0 # und ohne echo $ME
# Aufruf /var/run/whatever.sh # Ausgabe /var/run/whatever.sh whatever.sh
Danke Andi
Das Versionierungstool Git steht schon lange auf meiner Liste der Dinge, die ich mir mal anschauen will. Momentan nutze ich noch subversion. Doch während man mit subversion Änderungen nur in einem zentralen Repository speichern kann, bietet Git dezentrale Repositories, die auf Bedarf gegen ein zentrales Repository gemerged werden können.
Doch vor der Nutzung kommt zuerst die Installation. Sicherlich kann man Git auch aus den Quellen übersetzen, aber sowohl für Linux [1] als auch für den Mac [2] gibt es dafür Pakete. Die ersten Schritte sind in diesen beiden deutschen Tutorials [3] [4] erläutert. Ein ausführliches deutsches Tutorial gibt es von der Stanford Uni [5].
Am Anfang steht das Projekt, das man mit Git versionieren möchte. Das Terminal ist des Entwicklers liebster Freund und deswegen ist der volle Funktionsumfang von Git auch nur dort adressierbar (eine Eclipse Integration gibt es natürlich auch [6]). Aber ein Schritt nach dem anderen.
> git config --global user.name "Gero Klinkmann" > git config --global user.email me@example.com
Dann kann man sein erstes Git Repository mit git init ersellen. Bei mir liegt es auf dem Mac mini, auf dem im nächsten Schritt auch das zentrale Repository entstehen soll.
> cd ~/workspace/testGroovy > git init > git add . > git commit
Die Befehle sprechen für sich. Beim commit öffnet sich der vi Editor, damit man einen Kommentar für den jeweiligen Stand hinzufügen kann. Die Befehlssyntax des vi ist nicht gerade intuitiv, von daher für alle, die sie nicht kennen, kurz die notwendigen Befehle um den Kommentar hinzuzufügen:
bare zum zentralen Repository auf dem Mac.
> mkdir ~/git > cd ~/workspace/testGroovy > git clone --bare .git ~/git/testGroovy.git
Auf dem Linux Laptop soll ja ein dezentrales Repository entstehen. Dafür ist es notwendig, das zentrale Repository auf dem Mac zu klonen. Beide Rechner sind über ssh verbunden. Weiterhin wird beim Clonen das git-upload-pack (und zwar das von dem Rechner, wo das zentrale Repository liegt – bei mir also vom Mac) benötigt.
Um Problemen, wie bash: git-upload-pack: command not found vorzubeugen, sollte man den Ort (bei mir ist es /usr/local/git/bin/git-upload-pack) beim Clone Kommando mit angeben.
> cd ~/projekte > git clone --upload-pack /usr/local/git/bin/git-upload-pack \ ssh://username@server/full/remote/path/to/testGroovy.git testGroovy
Damit man das nicht ständig beachten muss, kann man das auch in der Git Konfigurationsdatei hinterlegen.
> cd ~/projekte/testGroovy > vi .git/config [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = ssh://username@server/full/remote/path/to/testGroovy.git uploadpack=/usr/local/git/bin/git-upload-pack receivepack=/usr/local/git/bin/git-receive-pack
Änderungen an den Sourcen werden zuerst im lokalen Repository über git commit -a versioniert. Auch bei diesem commit öffnet sich der vi Editor für einen Versionskommentar. Mit git push werden die Änderungen des lokalen Repositories dem zentralen Repository mitgeteilt.
> cd ~/projekte/testGroovy > git commit -a > git push
Begonnen hatte ich mit einem lokalen Repository auf meinem Mac. Über git clone –bar wurde ein zusätzliches zentrales Repository erstellt. Doch noch gibt es keine Verbindung zwischen den beiden. Dies geschieht durch einen Eintrag in der Git Konfigurationsdatei des lokalen Repositories.
> cd ~/workspace/testGroovy > vi .git/config ... # Verbindung zum zentralen Repository [remote "origin"] fetch = +refs/heads/*:refs/remotes/origin/* url = /full/path/to/git/testGroovy.git [branch "master"] remote = origin merge = refs/heads/master
Fazit:
Ein bisschen Konfiguration ist schon notwendig, wenn man mit Git zentrale und dezentrale Repositories gleichsam nutzen möchte. Für diesen Aufwand bekommt man aber ein sehr leistungsfähiges, stabiles und performantes Versionierungssystem, das nicht auf eine Verbindung zu einem zentralen Repository angewiesen ist.
Links:
[1] git-core – Core Pakete für Ubuntu
[2] git-osx-installer – Google Code Projekt
[3] kurzes deutsches Git Tutorial – auf interaktionsdesigner.de
[4] kurzes deutsches Git Tutorial – auf online-tutorials.net
[5] ausführliches deutsches Git Tutorial – der Stanford Uni
[6] EGit – Eclipse Plugin für Git
Ich mag Unix, hab ich das schon mal erwähnt? Alles, was auf der Kommandozeile möglich ist, kann man mit Skripten automatisieren.
Ein Thema beim Erstellen von Shell Skripten ist der Umgang mit Prozessen. Wer schon mal mit einer Unix Shell Bekanntschaft gemacht hat, wird die Befehle ps und kill kennen, mit denen man sich eine Übersicht über laufende Prozesse verschafft, bzw. sie beendet. Vielleicht ist auch bekannt, dass man mit kill -9 einem Wunsch einen Prozess zu beenden Nachdruck verleihen kann.
Was weniger bekannt sein dürfte (zumindest mir bis vor kurzem nicht) ist, dass man mit kill -0 auch feststellen kann, ob ein Prozess noch läuft. Denn mit dem Befehl kill kann man einem Prozess auch Signale schicken, zu denen auch schon das vorhin erwähnte Signal 9 gehört.
Alles was man dazu benötigt ist die Prozess ID (pid). Diese erhält man über die Shell Variable $!. In Zeile 4 des Beipiels wird sie gleich mit dem Start eines Prozesses in einer Variablen abgespeichert. In der darauf folgenden Zeile wird dieser pid dann das Signal 0 über den Befehl kill gesendet.
Findet der Kernel diese pid in seiner Prozesstabelle erhält man als Returnwert 0, wenn nicht eine 1. So muss man nicht selbst umständlich in der Prozesstabelle suchen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | #!/bin/bash pid="" ./longrun.sh & pid=$! kill -0 $pid 2>/dev/null if [ $? -eq 0 ] then echo "existing process $pid" else echo "no process with pid: $pid" fi exit 0 |
Eines muss ich mal an dieser Stelle festhalten. Man kann zwar nicht mit der Windows Kommandozeile richtig arbeiten, aber sie hat ein tolles tree Kommando. Tree macht genau das, was der Name sagt. Es stellt ein Verzeichnis mit seinen Dateien und Unterverzeichnissen als Baum dar. Optional kann man noch angeben wie tief dieser Baum angezeigt werden soll.
Warum dieses Kommando unter Linux und MacOs nicht vorhanden ist, ist mir schleierhaft, zumal es in der Version 8 der SuSE Linux Distribution meines Wissens noch enthalten war. Lang ist’s her. Wer den Grund weiß, möchte mich bitte in den Kommentaren erleuchten.
Doch wer auf den optionalen Parameter für die Darstellung der Verzeichnistiefe verzichten kann, dem kann geholfen werden. Eine Kombination des find und sed Kommandos versteckt in einem alias ergibt fast die gleiche Ausgabe auf der shell.
alias tree="find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'"
via:
macnotes.de – Baumansicht mit Tree
Umlaute sollten in der heutigen Zeit eigentlich keine Probleme mehr darstellen. Eigentlich!
Denn meldet man sich über den Putty z.B auf einem Linux Server an, dessen Spracheinstellungen:
> locale LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=
durchaus Umlaute unterstützen sollte, es aber dennoch nicht möglich ist, diese im Editor vi einzugeben, dann hat man doch ein Problem.
Schuld ist in diesem Fall aber weder der vi oder dessen größerer Bruder vim, sondern die Einstellungen vom Putty. Diese sollte man auch (über change settings -> Translation) auf UTF-8 umstellen.
Dann klappt es auch mit den Umlauten.
