Ich wollte nur [...] und dann ist das Universum explodiert.

Projects
Books
Archive
About









    Permalink
  1. Bash | minimal-bash-debug

    Bei Bash Scripten gibt es ja genug Möglichkeiten zu debuggen. Jeder der Bash Scripte schreibt, hat da so seine eigenen Vorlieben. Nachdem ich etwas geforscht hatte fand ich diverse Methoden a la:

    #!/bin/bash
    _DEBUG=true
    if [ "$_DEBUG" == "true" ]; then echo "some debug informations" ; fi

    Auch schön fand ich den eingebauten Debugmodus der Shell:

    $ sh -x script.sh

    Aber auch sehr umfangreiche Tools wie log4sh sind vorhanden. Ganz zu Schweigen von wahllosen “echo’s” die über das ganze Skript verteilt sind. Irgendwie gefiel mir aber keine der Möglichkeiten so wirklich. Der Code wird unlesbar, die Ausgabe ist zu kryptisch oder der Lernaufwand ist jenseits von Gut und Böse. Deshalb habe ich mich hingesetzt und überlegt, wie ich eine Debugging-Engine gerne hätte. Wie müsste sowas aussehen, damit ich es verwenden würde?

    • Code sollte nicht verunstaltet werden.
    • Debug Informationen sollten gut leserlich ausgegeben werden.
    • Debug Nachrichten sollten sich leicht zu erzeugen sein.
    • Sollte sehr einfach abschaltbar und skalierbar sein.
    • Minimaler Umfang des Gesamtsystems

    Nunja, im typischen Sonntag Nachmittag Größenwahn hab ich mich bemüht meine Anforderungen an den Bash Debugger umzusetzen. Ob es mir gelungen ist lasse ich jetzt mal dahingestellt, denn das ist mit Sicherheit Ansichtssache. Aber das aus dem Bedarf heraus entstandene minimal-bash-debug hat mich dann doch einigermaßen zufrieden gestellt.

    Download

    
    $ cd path/to/your/bashscript
    $ wget http://github.com/noqqe/minimal-bash-debug/raw/master/.minimal-bash-debug
    $ chmod +x .minimal-bash-debug


    Implementation

    Das runtergeladene (wirklich sehr schmale) Script dient jetzt als Auswerter für die Debug Informationen. In das Bash Script, welches es zu debuggen gilt, muss nun folgende Funktion eingefügt werden. Mein Ziel Dabei war es den Snippet der Implementierung so klein wie nur irgendwie möglich zu halten, um das Skript nicht zu verunstalten.

    
    debug() {
      debug=2 # set debug level 0|1|2|3
      if [ -x .minimal-bash-debug ]; then
      ./.minimal-bash-debug $debug $1 $2 "$3"
      fi
    }


    Usage

    Die Implementation der Funktion debug() in das eigene Skript hat mehrere Vorteile. Aber zuerst zur Benutzung.

    debug 2 syslog "Variable VAR is $VAR"
    debug 3 echo "Variable FOO is $FOO"

    Das ganze ist simpel.

    • debug aufrufen (debug)
    • debug level bestimmen (2)
    • debug mode auswählen (echo|syslog)
    • debug message übergeben (Variable FOO is $FOO)

    Das war auch schon der ganze Zauber. Das schöne daran ist, ist das .minimal-bash-debug Script einmal nicht mehr vorhanden/nicht ausführbar oder das debug level einfach auf 0 gesetzt, verfallen alle debug Zeilen in sofortiges Stillschweigen.

    Der kurze Auszug der Erklärung ist natürlich relativ wenig. Deswegen gibt es auf Github http://github.com/noqqe/minimal-bash-debug/ ein Beispiel der Benutzung und ein README.

    example.sh: http://github.com/noqqe/minimal-bash-debug/raw/master/example.sh


  2. Permalink
  3. Bash | ZRE und $RANDOM

    Zugegeben, dieser ganze Zombie-Sh!t unterhält mich länger, als es mir lieb ist. Insbesondere die aktuell stattfindende Blockschulwoche, trägt zur außergewöhnlich häufigen Nutzung bei.

    In den meisten Durchläufen des ZRE beendet es ganz von alleine die Simulation, weil entweder keine Humans oder Zombies mehr am Leben sind. Auf Letzteres trifft das natürlich immer irgendwie zu. Aber das ignoriere ich jetzt einfach mal. Wenn eine der beiden Seiten als Sieger hervor geht eben.

    CC by Drunken Monkey

    In wenigen Fällen® kommt es allerdings vor, das beide Seiten gleichmäßig stark an Mitgliedern gewinnen. Und zwar mehr als 150.000 ca. Die Chance diesen Case zu treffen würde ich jetzt auf 1:50 schätzen. Habe ihn heute 3 mal getroffen. Wie oft habe ich wohl ca. gespielt? Traurig.

    Wenn dieser Case eintritt, nimmt die Simulation einen etwas schrägen Verlauf.

    • Wachsende Bevölkerung: Die Anzahl der Mitglieder einer Seite wird mit
      local size=$(($RANDOM % $humans + 1))
      humans=$(($humans + $size))

      berechnet.
    • Maximale Opfer eines Angriffs: Die Anzahl der $victims ermittelt ZRE folgendermaßen:
      defenders=$(($RANDOM % $zombies +1))
      victims=$(($RANDOM % $defenders + 1))
      zombies=$(($zombies - $victims))

    Die Problemstellung beläuft sich eigentlich auf $RANDOM. $RANDOM erzeugt einen “zufälligen” Integerwert von 0 bis 32767.

    Die Erzeugung der Unterstützung addiert sich immer wieder sofort auf den Wert der jeweiligen Rasse. Die Anzahl der Opfer allerdings errechnet sich aus einem Teil der Verteidiger, welcher wiederrum nur ein Teil der gesamten Rasse darstellt.

    Klartext: Die Wahrscheinlichkeit, dass (max.) 32767 Mitglieder Opfer werden ist wesentlich geringer als die Wahrscheinlichkeit 32767 Mitglieder Support zu bekommen. Das führt zu unverhältnismäßig großem Wachstum im Environment.

    Nach einiger Überlegung habe ich beschlossen die Werte der Kämpfe nicht anzupassen und stattdessen etwas anderes Einzuführen.

    Naturkatastrophen. Diese sollen automatisch bei Überschreitung eines Limits (300.000 Einwohner) oder einfach nur sporadisch etwas aufräumen. Vulkan, Hurricane oder Erdbeben. Alles dabei. Wer genau, wieviele und warum bei diesem Event ums Leben kommen entscheidet wie immer $RANDOM.


  4. Permalink
  5. Bash | the zombie-revolution-environment

    Wer kennt eigentlich noch MUD‘s? Diese textbasierten Rollenspiele über Telnet. Uralt und genau genommen dürfte mir das auch nichts sagen, denn das war vor meiner Zeit.

    Wie dem auch sei. Vor kurzem saß ich nachts vor meiner Shell und suchte irgendeine Ablenkung. Dachte dann an ein Python Projekt, welches ich zusammen mit Chris vor ca. 2 Jahren mal aufgegriffen hatte. Ich fand die Idee damals schon gut, aber es mangelte einfach an Python Kenntnissen.

    Ich habe dann (auch wenn es schon spät war) versucht, das nochmal in Bash abzubilden. Nur ein bisschen interessanter. Eine kleine Welt kam dabei heraus, wie schon damals ausgedacht. In dieser Welt passieren Dinge, die durch Zufall ausgewählt und gewichtet werden, was sich auf die Bewohner dieser “Welt” auswirkt. In meiner jetzigen Version sollte allerdings bisschen was passieren. Irgendwer musste da kämpfen oder sowas. Ich ließ also Zombies und Humans auf dieser Welt gemeinsam leben. Es werden neue Lebewesen geboren, sie sterben wieder, greifen einander an und so weiter.

    Im Klartext habe ich nichts anderes in dieses Bash-Script gepackt als die Anzahl der Menschen/Zombies auf der Welt und eine Hand voll Funktionen definiert, die “Events” darstellen, die von einer Schleife und einem Case bei jeder Runde zufällig ausgewählt werden. Das war’s auch schon. Eigentlich hat mich mehr der Grad an Zufälligkeit interessiert, der den Verlauf der erstellten Welt beeinflusst, wie viele Zombies greifen wie viele Menschen auf einer imaginären Farm an, können sich die Menschen wehren oder werden Sie von der Übermacht der Zombies einfach überrannt? Wie viele Opfer gibt es? Wer rottet wen zuerst aus?

    Das war letzten Endes auch der Punkt der mich an ZRE (so hab ich das Script genannt) immernoch unterhält und amüsiert. Jedesmal wenn ich es starte, beginnt ein total neuer Verlauf dieser Welt, wer wann wo wen angreift und letzten Endes besiegt.

    Ich hab das zombie-revolution-environment auf github hochgeladen. Ich weiss nicht wirklich was es ist, aber es unterhält mich.

    http://github.com/noqqe/zombie-revolution-environment
    zombie-revolution-environment als RAW.

    Usage ist relativ einfach.

    $ wget http://github.com/noqqe/zombie-revolution-environment/raw/master/zre.bash
    $ ./zre.bash

    Ein beispielhafter Verlauf klemmt auch in dem github Repository.

    Für neue Ideen, Bugreports, Meinungen, Flamewars oder Shitstorms bin ich wie immer dankbar.


  6. Permalink
  7. Twidge | twidge-sh merged!

    Yay. Thanks to John Goerzen.

    http://github.com/jgoerzen/twidge/pull/19

    twidge-sh im nächsten Ubuntu/Debian? Maybe.


  8. Permalink
  9. Git | Verschiedene Repos zusammenführen

    In einem Anfall des Ordnungswahns entschloss ich mich im Mai (oder einem deren anderen 11 Monate des letzten Jahres) dazu, mein textbasiertes Wiki, meine Dotfiles und meine Scripte in separaten Git-Repos zu verwalten und zu verteilen. Mit der Zeit merkt man aber, dass das ziemlicher Unsinn war.

    Kurz: Ich brauchte eine Lösung, wie ich alle 3 Repositories (ohne History-Verlust) zusammen gemerged bekomme.

    /repos/
    |-- dotfiles.git
    |-- scripts.git
    `-- wiki.git

    Hierfür hat Zrajm C Akfohg schon eine wunderbare schnelle Lösung gefunden.
    Zuerst ein neues Repo erstellen:

    mkdir ~/repos/noqqe.git
    cd ~/repos/noqqe.git
    git init

    Im Grunde wird jedes Repository in einen separaten Branch gefetched:

    git fetch ~/repos/dotfiles master:dotfiles
    mkdir dotfiles #Subdir fuer dotfiles

    Um die Files im neuen Branch jetzt in einen Unterordner umzumappen hat Zrajm auch einen wunderbaren Weg gefunden:

    SUBDIR_NAME=dotfiles
    BRANCH_NAME=dotfiles
    git filter-branch --index-filter \
        'git ls-files -s | \
            sed "s-\t-&'"$SUBDIR_NAME"'/-" | \
            GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && \
            mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE
        ' "$BRANCH_NAME"

    Wenn alles erfolgreich war, kann man den neuen Branch mit dem Master zusammenführen:

    git merge dotfiles

    und das Spiel wie beschrieben von vorne beginnen.


  10. Permalink
  11. Twitter on CLI | Twidge Interactive Shell

    Seit längerem benutze ich John Goerzen‘s CLI Twitter Client Twidge. Weniger zum Posten als zum Lesen, aber dennoch kann ich dieses Stück Software nicht mehr weg denken. Ich finde Twidge erntet allgemein zu wenig Beachtung. Wie dem auch sei, sieht eine durchschnittliche Nutzung von Twidge wie folgt aus:

    $ twidge setup
    $ twidge lsrecent
    <timpritlove> Verkannt, ignoriert, nahezu vergessen - aber sinnvoll, nützlich und wertvoll: das Semikolon!
    [...]
    $ twidge update "Ich benutze gerade Twidge"

    Bei intensiver Nutzung nervt die Syntax allerdings etwas. Deshalb hab ich mich hingesetzt und eine Twidge-Shell gebaut.

    Die angepasste Shell “twidge-sh” kann einfach über Aufruf ./twidge-sh gestartet werden.

    $ wget http://github.com/noqqe/twidge/raw/master/twidge-sh
    $ chmod +x twidge-sh
    $ ./twidge-sh
    noqqe@twitter> lsrecent
    <rivva> Skype jetzt für Android verfügbar – Skype Blog auf
    Deutsch http://rivva.de/QajD
    [...]
    noqqe@twitter> update "Ich benutze gerade Twidge-Shell"
    noqqe@twitter> lsdm
    noqqe@twitter> follow technicallife

    Die Twidge-Shell hat weiterhin folgende Features:

    • Der Prompt wird aus der .twidgerc generiert (username@service>)
    • Alle Standart Kommandos von Twidge werden automatisch komplettiert und sind benutzbar (z.B. user@service> lsrecent)
    • Alle in der .twidgerc definierten Aliase werden übernommen und sind ebenfalls verwendbar. (z.B. user@service> rls)
    • Die Twidge-Shell funktioniert weiterhin als ganz normale Shell mit allen Zusätzen und Funktionen.

    Ich habe mich dabei an Ryan Tomayko’s git-sh orientiert, der ähnliches für Git gebaut hat. Was übrigens auch wirklich gut funktioniert.

    Mein Twidge-Fork auf Github (mit Twidge-sh)
    Twidge von John Goerzen
    Twidge zum Download für Debian
    Twidge zum Download für Ubuntu
    Twidge-Shell Script zum Download