Monthly Archives: January 2009

Farbige Nicknames in irssi

Als Fan von Programmen für die Konsole benutze ich natürlich irssi als IRC-Client. Für viele Funktionen, die im Standard-Umfang nicht vorhanden sind, gibt es Scripte, Tux hatte da ja auch selbst mal eins geschrieben und hier im Blog vorgestellt. Um den Chatverlauf einfacher verfolgen zu können, existiert beispielsweise das Skript nickcolor.pl, das die Nicknames der Nutzer einfärbt. Die Beschreibung in der Übersicht der Skripte ist kurz und knapp:

assign a different color for each nick

Das Skript bildet per Default einen simplen Hashwert über den Nickname, wählt anhand dessen eine Farbe aus und behält diese dann bei. Bei gleichen Nicks ist das dann immer die gleiche Farbe, was ja auch ganz sinnvoll ist.

Das Skript kann darüber hinaus noch mehr, um das rauszufinden, muss man aber einen Blick in den Quelltext werfen, entscheidend ist folgende Subroutine:

sub cmd_color {
  my ($data, $server, $witem) = @_;
  my ($op, $nick, $color) = split " ", $data;

  $op = lc $op;

  if (!$op) {
    Irssi::print ("No operation given");
  } elsif ($op eq "save") {
    save_colors;
  } elsif ($op eq "set") {
    if (!$nick) {
      Irssi::print ("Nick not given");
    } elsif (!$color) {
      Irssi::print ("Color not given");
    } elsif ($color < 2 || $color > 14) {
      Irssi::print ("Color must be between 2 and 14 inclusive");
    } else {
      $saved_colors{$nick} = $color;
    }
  } elsif ($op eq "clear") {
    if (!$nick) {
      Irssi::print ("Nick not given");
    } else {
      delete ($saved_colors{$nick});
    }
  } elsif ($op eq "list") {
    Irssi::print ("nSaved Colors:");
    foreach my $nick (keys %saved_colors) {
      Irssi::print (chr (3) . "$saved_colors{$nick}$nick" .
		    chr (3) . "1 ($saved_colors{$nick})");
    }
  } elsif ($op eq "preview") {
    Irssi::print ("nAvailable colors:");
    foreach my $i (2..14) {
      Irssi::print (chr (3) . "$i" . "Color #$i");
    }
  }
}

Hier wird für irssi ein Befehl /color definiert, den man mit folgendem ersten Argumenten bzw. weiteren Befehlen aufrufen kann:

  • save
  • set
  • clear
  • list
  • preview

Was kann man nun mit den einzelnen Befehlen anstellen? Ich gebe mal jeweils ein Beispiel mit der dazugehörigen Ausgabe, allerdings ohne Farben.

/color save gibt nichts weiter aus, speichert aber die mit set festgelegten Farben in der Datei ~/.irssi/saved_colors. Diese gespeicherten Farbzuordnungen werden beim Neustart von irssi bzw. Neuladen des Skripts wieder eingelesen.

/color set foo 7 gibt ebenfalls nichts aus, legt aber eine Zuordnung der Farbe 7 zum Nickname foo fest. 7 ist in dem Fall das, was in PuTTY gelb und auf der Konsole braun, in anderen Terminals eher orange aussieht. (Mehr zu diesem verwirrenden Thema in der englischen Wikipedia.)

/color clear foo löscht die gesetzte Farbe für foo wieder, gibt aber ebenfalls keine Statusausgabe zurück. Interessant werden dann die letzten beiden Funktionen.

/color list zeigt die aktuell gesetzten Zuordnungen in einer Liste an, bei mir sieht das derzeit so aus, die Namen sind in den Farben, wie sie auch im Chat auftauchen, die Zahlen dahinter sind erst bei dem Kopieren aus der Konsole zum Vorschein gekommen, geben aber die Farben wieder:

Mo|23:06:25 -!- Irssi: Saved Colors:
Mo|23:06:25 -!- Irssi: An-Tet (9)
Mo|23:06:25 -!- Irssi: Fabian (7)
Mo|23:06:25 -!- Irssi: Ge0rG (12)
Mo|23:06:25 -!- Irssi: IseeU (13)
Mo|23:06:25 -!- Irssi: Mupfy (3)
Mo|23:06:25 -!- Irssi: priority (3)
Mo|23:06:25 -!- Irssi: schlotze (4)
Mo|23:06:25 -!- Irssi: StarWarsFan (12)
Mo|23:06:25 -!- Irssi: StefanG (3)
Mo|23:06:25 -!- Irssi: SvenG (13)
Mo|23:06:25 -!- Irssi: thndr (12)
Mo|23:06:25 -!- Irssi: thunder (12)
Mo|23:06:25 -!- Irssi: zozi (6)
Mo|23:06:25 -!- Irssi: _MrTux_ (7)
Mo|23:06:25 -!- Irssi: _Tux_ (7)

Last not least kann man sich mit /color preview auch noch eine Liste der verfügbaren Farben ausgeben lassen:

Mo|23:19:39 -!- Irssi: Available colors:
Mo|23:19:39 -!- Irssi: Color #2
Mo|23:19:39 -!- Irssi: Color #3
Mo|23:19:39 -!- Irssi: Color #4
Mo|23:19:39 -!- Irssi: Color #5
Mo|23:19:39 -!- Irssi: Color #6
Mo|23:19:39 -!- Irssi: Color #7
Mo|23:19:39 -!- Irssi: Color #8
Mo|23:19:39 -!- Irssi: Color #9
Mo|23:19:39 -!- Irssi: Color #10
Mo|23:19:39 -!- Irssi: Color #11
Mo|23:19:39 -!- Irssi: Color #12
Mo|23:19:39 -!- Irssi: Color #13
Mo|23:19:39 -!- Irssi: Color #14

Alles in allem eine sehr praktische Erweiterung für irssi, wenn man weiß, wie man sie bedienen muss. ;-)

HTML-Entities mit WP-Syntax 0.9.2

Für die Darstellung von Code-Schnipseln, speziell das Syntax-Highlighting setzen wir das Plugin WP-Syntax ein. Probleme gab es bisher immer mit Code, der die speziellen HTML-Entities enthielt, also hauptsächlich die öffnenden und schließenden spitzen Klammern, die in der einen oder anderen Sprache irgendwie als Vergleichsoperatoren eingesetzt werden: < und >.

Bisher bin ich Problemen damit so aus dem Weg gegangen, dass ich entsprechende Zeichen im Beitragseditor durch &lt; und &gt; ersetzt hatte. Damit das Plugin damit umgehen konnte, war bei jedem Update eine kleine Änderung notwendig, für Version 0.9.1 sah der Patch beispielsweise so aus:

--- wp-syntax.php  2008-08-24 19:22:12.000000000 +0200
+++ wp-syntax.php  2008-08-25 15:26:48.000000000 +0200
@@ -97,7 +97,8 @@
     $line = trim($match[2]);
     $code = wp_syntax_code_trim($match[3]);

-    $geshi = new GeSHi($code, $language);
+    $geshi = new GeSHi(htmlspecialchars_decode($code), $language);
     $geshi->enable_keyword_links(false);
     do_action_ref_array('wp_syntax_init_geshi', array(&$geshi));

Ab WP-Syntax 0.9.2 ist das nicht mehr notwendig. Die Release Notes sagen ganz lapidar:

**0.9.2** : Updated to use GeSHi v1.0.8.2; Added optional `escaped=”true”` support in case code snippets are already escaped with html entities.

In der Praxis sieht das dann so aus:

    <pre lang="xml" escaped="true">
    &lt;xml&gt;Hello&lt;/xml&gt;
    </pre>

Das vereinfacht zukünftige Upgrades von dem Plugin, ist also eine feine Sache. Für vergangene Beiträge musste ich jetzt allerdings nochmal von Hand diesen Parameter setzen. Wenn mir da irgendwo was durch die Lappen gegangen sein sollte, einfach mal kurz anpiepsen, dann behebe ich das.

Kein Usenet bei O₂

Wir haben in unserer WG einen DSL-Anschluss, der Provider ist O2. Auch wenn da öfter als mir lieb ist die Verbindung neu aufgebaut wird und der von denen gestellte Router besser funktionieren könnte, läuft das ganze doch recht zufriedenstellend.

Soweit so gut, nun bin ich von Fli4l und eisfair gewohnt das Usenet zu nutzen, dort laufen die Diskussionen zwischen Nutzern in Newsgroups ab, die auf einem freien Newsserver verfügbar sind und die ich auch regelmäßig nutze. Dieser Server hat allerdings nur diese Gruppen gelistet. Andere Gruppen aus den Weiten das Usenet wie z.B. de.comp.text.tex oder de.comp.lang.perl.misc habe ich vor unserem Umzug 2007 auf dem Newsserver von T-Online abgerufen, aber nur gelegentlich gelesen, so dass ich hier bisher darauf verzichtet habe.

Heute nun hatte ich eine Frage bezüglich Perl und hab die reflexartig erstmal über Google Groups in de.comp.lang.perl.misc abgesetzt. Grundsätzlich würde ich die Gruppe aber schon gern in einem normalen Newsreader lesen. Ich dachte mir, dass O2 wohl auch einen Newsserver bereitstellt und suchte nach der entsprechenden Information. Auf der Homepage von denen war leider nichts zu finden, also rief ich die Hotline an.

Das Telefonat dauerte sechseinhalb Minuten wovon gefühlt fünf Minuten Ansagen und Melodien vom Band kamen. Die Mitarbeiter dort waren alle ganz freundlich, nur leider kam derjenige, der dann bescheid wusste mit der enttäuschenden Nachricht um die Ecke: »Newsserver gibt’s nicht bei O2.« Schade! :-(

GRUB Error 2

Manchmal findet man seltsame Sachen heraus. Wusste hier jemand, dass nicht alle Versionen von GRUB alle Versionen von ext3 lesen können? Ok, klingt erstmal logisch, dass das für ziemlich alte Versionen von GRUB und für ziemlich neue Versionen von ext3 gilt. Gut da fragt man sich erstmal, wie es denn überhaupt Versionen bei ext3 geben kann, aber egal, vielleicht fang ich die Geschichte doch besser vorn an.

Letze Woche hat sich eine meiner alten Festplatten verabschiedet, wo zu Testzwecken ein Debian Sid installiert war. Gestern bekam ich von Tux Ersatz und heut dachte ich mir, schiebst Du »mal eben kurz« wieder das System drauf. Die Installation verlief auch zügig und glatt. Den Bootloader ließ ich in den MBR von /dev/hdc schreiben und laden wollte ich das ganze wie üblich, nämlich über folgenden Eintrag im GRUB von /dev/hda (das zu nem Ubuntu gehört):

title       hdc: Debian Sid
configfile  (hd2,0)/boot/grub/menu.lst

Das funktioniert üblicherweise wunderbar. Man gelangt zunächst in das Bootmenü vom GRUB auf /dev/hda und von dort über obigen Eintrag in das Menü von /dev/hdc. So können die Systeme auf jeder der Platten ihre eigenen Bootloader eigenständig verwalten und kommen sich auch bei Kernelupdates nicht ins Gehege. Heute führte das allerdings zum Error 2. Das Handbuch von GRUB sagt dazu lapidar:

2 : Bad file or directory type
This error is returned if a file requested is not a regular file, but something like a symbolic link, directory, or FIFO.

Die Recherche nach der Lösung zu solchen Fehlern gestaltet sich natürlich schwierig. Ich hatte ein wenig Glück und fand diesen Thread im Ubuntu-Forum. Dort näherte man sich Stück für Stück einem ähnlichen Problem. Ich konnte ebenfalls mit der GRUB-Shell verifizieren, dass das GRUB aus dem MBR meiner /dev/hda nicht in der Lage war das Filesystem auf /dev/hdc1 zu lesen, obwohl letzteres ein sauberes (fsck von GRML drüberlaufenlassen) ext3 war. Mit anderen ext3 kam das bis dahin ja auch klar. Recht weit unten in dem Thread schreibt dann jemand:

Did you upgrade to Hardy from an earlier version of Ubuntu? Then you might of have older version of grub which cannot read ext3 partition with 256 inodes.

Da hab ich nicht schlecht geschaut. Das heißt einerseits wie eingangs angedeutet, dass es vorher (dieses mysteriöse »früher«) ext3 nur mit weniger inodes gab und ältere Versionen von GRUB mit so vielen nicht umgehen können. Das GRUB ist tatsächlich ein wenig älter, das Ubuntu ist ungefähr 2005 auf die Kiste gekommen, also wahrscheinlich ursprünglich als Dapper Drake oder vielleicht sogar noch Breezy Badger. Na und der aktuelle Installer von Debian Lenny scheint derart neue ext3-Formatierungen zu schreiben. Einfaches Neuschreiben des Bootloaders mit dem aktuellen GRUB von Intrepid Ibex hat dann jedenfalls im Handumdrehen das Problem behoben. Ich sag ja, seltsame Sachen gibt’s.

Erfahrungsbericht »Getting Things Done«

An diesem Wochenende hatte ich die Gelegenheit ein Buch zu lesen, das jetzt schon einige Zeit hier bei mir rumliegt. Ich zitiere mal Auszüge von Seite 4:

7. Auflage, November 2007
Titel der amerikanischen Originalausgabe: »Getting things done«

Ich kann mich nicht genau erinnern, wann ich das Buch gekauft habe, muss wohl so Anfang 2008 gewesen sein – so lang lag das hier in der Sonne. Der Umschlag ist ausgeblichen und wie ich gerade bei Amazon sehe, gibt es seit Mai wohl eine neue deutsche Übersetzung, die hoffentlich etwas besser ist als meine. Dass das Buch hier so lang ungelesen rumlag, zeigt wohl, dass ich es tatsächlich brauche.

Meine Mitautoren hier im Blog sind seit einiger Zeit schon intensive Nutzer von GTD und ich habe auch andernorts viel positives über die Methoden (die Methoden, nicht das Buch selbst) gehört. Nun denn, der feste Vorsatz (was gibt es klassischeres zum Jahresanfang) ist gefasst: ich werde das Buch durcharbeiten und ich werde meine Erfahrungen in diesem Blog veröffentlichen.

Ich erwarte folgendes:

  • Ich werde mich zu Anfang schwer tun mir die neuen Abläufe anzugewöhnen. Das dürfte nicht sehr ungewöhnlich sein, mit zunehmendem Alter (ich gehe immerhin auch auf die 30 zu) nimmt die Lernfähigkeit ab und sein eigenes Verhalten nachhaltig zu ändern fällt den meisten Menschen ziemlich schwer.
  • Ich werde meinen ganz persönlichen und ureigenen Weg finden, die Methoden umzusetzen. Der Erfahrungsbericht kann daher für andere nur als Anregung dienen.
  • Sobald es an die Umsetzung mit irgendeiner Form von Software geht, werde ich auf freie Software zurückgreifen und zur Not meine eigenen Tools entwickeln müssen, weil mir die anderen Tools alle nicht passen (siehe auch der letzte Punkt).

Ich erhoffe oder verspreche mir davon:

  • Wieder öfter den Kopf wirklich frei kriegen mit allen positiven Nebenwirkungen davon.
  • Nichts wichtiges vergessen. Ich vermute, dass es in Zukunft nicht weniger Verantwortung für mich selbst und andere geben wird und wirklich wichtige Sachen verpeilen wäre da ziemlich doof.

Ich werde die folgenden Beiträge alle hier verlinken, um eine Übersicht zu schaffen. Stay tuned! ;-)