Jan-Piet writes about GhettoPush, so I don’t have to. 🙂
GhettoPush is a UNIX daemon (written in Perl) that will monitor any IMAP server for new message events and generate a push message. Most of the time, I hear the push message come in on the iPhone before I notice the new message on my workstation. Please give it a try and let me know how you like it.
Der Perl-Substitution-Operator s/// gibt als Rückgabewert die Anzahl der gemachten Ersetzungen raus:
my $string = "aaabaabbbaa";
my $replaced = ($string =~ s/a/b/g);
Steht hier, damit ich es nicht vergesse. 🙂
Problem: Can't do setuid (cannot exec sperl)
Solution (CentOS/RedHat): yum install perl-suidperl
Solution (Debian/Ubuntu): apt-get install perl-suid
An den Feiertagen hatte ich eine Klasse in Ruby geschrieben, die mir dauerhaft helfen sollte, ein Problem zu lösen, das mir alle Nase lang Kopfschmerzen bereitet. Die sah auch ganz rund aus. Da ich kein Softwareentwickler bin, bin ich auf sowas ja immer richtig stolz.
Weil aber die Kundschaft mit Ruby nicht so gut zurechtkommt und das ganze in einem Perl-Umfeld (andere selbstgeschriebene Perl-Module und so) laufen soll, habe ich die Klasse gestern nach Perl portiert. Eine unangenehme Sache: Erstens hat das Portieren nach Perl länger gedauert als die ursprüngliche Schreiberei in Ruby. Zweitens war das Perl-Modul nicht nur umständlich zu schreiben (wenn man Ruby kennt ist man für Perl-Objekte verdorben) sondern sieht drittens auch noch häßlich aus. Man ist ja auch Ästhet. 😉
Viertens steht die Perl-Variante mit dreimal soviel Speicherverbrauch da.
Und fünftens läuft sie in einem Drittel der Zeit durch. Bei Laufzeiten im Stundenbereich (für die Ruby-Variante) darf das wohl als durchschlagendes Argument gelten. 😮
Hilferuf vom Kunden: Er hatte ein schon etwas älteres Perl-Script von mir erweitert und mußte schmerzlich feststellen, daß das vom Script generierte Excel-File alle Strings nach 256 Zeichen abschnitt. Kurzes Nachlesen in der Doku von Spreadsheet::WriteExcel ergab jedoch, daß die maximale Länge von Strings eigentlich bei 32767 Zeichen liegen sollte.
Nachdem diese Diskrepanz erst einmal aufgedeckt war, war der Fall schnell gelöst: Das aus dem Jahr 2003 oder 2004 (genaues weiß man nicht mehr) stammende Script benutzte die Version 0.42 von Spreadsheet::WriteExcel. Aktuell ist jedoch die Version 2.18. Es hatte also in der jüngeren Vergangenheit eine gewisse Weiterentwicklung gegeben.
Wirklich gute Perl-Module verändern ihr API nie, sondern bauen es nur aus. So auch in diesem Fall: Nach der Aktualisierung lief das Script noch genau so durch wie früher und für mich war lediglich das Problem mit den 256 Zeichen behoben. Auch wenn ich gerade versuche, ein wenig Ruby zu lernen (wegen der wirklich gelungenen Objektorientierung), ist diese Kontinuität genau das, was ich an Perl so liebe.
Aber genug davon, denn ich stelle grade fest, daß ich klinge wie ein alter Sack, der seine in den 70ern geschriebenen Fortran-Programme für das Maß aller Wartbarkeit hält. 😉
Damit habe ich jahrelang Probleme gehabt, bis ich der Sache schließlich im Detail nachgehen mußte. Wenn man den Exitcode eines von Perl aufgerufenen externen Programms wissen will, muß man dazu den Rückgabewert um 8 Bits nach rechts shiften:
my $out=`/usr/local/bin/blahfasel`;
my $rc = $?>>8;
Die Information findet sich in man perlfunc bei der system-Funktion.
Hey, komm, jetzt schreibe auch ich nochmal was dazu, schon allein, um meinen Anspruch als A-List-Frickelblogger mit Impact zu demonstrieren.
“Is Perl relevant any longer?”
wird bei Tim O’Reilly gefragt. Dabei stellt sich natürlich als erstes die Gegenfrage, welche Relevanz eine solche Frage haben soll. Selbstverständlich ist Perl relevant, solange damit gearbeitet und programmiert wird.
Im Web-Bereich mag Perl vielleicht an Verbreitung verloren haben, da es lange Zeit ausschließlich mit CGI in Verbindung gebracht wurde und in dieser Umgebung aufgrund des on-the-fly Übersetzungsvorgangs auf Anhieb eher schlecht skaliert. Im Gegensatz dazu lassen sich mit PHP aus dem Stand wesentlich schneller Ergebnisse zusammenschustern, ohne sich lange mit dem eher krampfig aufgestellten mod_perl oder anderen CGI-Beschleunigern auseinandersetzen zu müssen. Darüber, welche Ansprüche an Qualität und Sicherheit manche PHP-Machwerke dann auch im Falle großer und bekannter Projekte erfüllen können, wollen wir bei der Gelegenheit allerdings nicht reden.
So manchem Webdesigner™ würde eine mäßige Einstiegshürde jedenfalls nicht schaden. Soviel dazu.
Zurück zu Tim O’Reilly: Die Zeiten, in denen man zu jedem Mist ein eigenes Perl-Buch auf den Markt werfen konnte, das dann auch noch begierig gekauft wurde, nur weil “Perl” auf dem Deckel geschrieben stand, gehen scheinbar ihrem Ende zu. So schlimm kann die Lage allerdings doch wieder nicht sein, denn mit “Perl Testing: A Developer’s Notebook” und “Perl Best Practices” hat O’Reilly für diesen Monat schon wieder zwei neue Schinken in Arbeit, die die Welt vermutlich nicht braucht.
Die vage Aussicht auf Perl 6 sorgt derweil für Unruhe, vermutlich weil viele Perl-Nutzer noch nie in der Situation waren, sich auf eine neue Version “ihrer” Sprache einstellen zu müssen. Keine Angst, das schafft ihr schon. In der EDV zu arbeiten, bedeutet glücklicherweise noch immer Veränderung, auch wenn es in der Großindustrie so manche Vertreter gibt, die sich nichts mehr wünschen, als alle Verhältnisse für immer zementieren zu können.
Sollte Perl dann in hoffentlich ferner Zukunft wirklich in der Bedeutungslosigkeit verschwinden, machen wir demzufolge halt was ganz anderes. Die Welt dreht sich im Zweifelsfall auch ohne Perl weiter.
Das sind MIME-encoded Words laut RFC 1522 2047:
=?UTF-8?B?5Pb8LmV4ZQ==?=
=?KOI-8?B?YW5uYWtvdXJuaWtvdmEuc2Ny?=
=?ISO-8859-15?B?TfxsbGVyTWVpZXJTY2h1bHplLlBQVA==?=
Codiert werden die z.B. so:
echo "äöü.exe" |
perl -MMIME::Words=:all -ne 'chomp;$_=encode_mimeword($_,B,"utf-8");print"$_\n"'
oder defensiver:
echo "äöü.exe" |
perl -MMIME::Words=:all -pe 'chomp;$_=encode_mimewords($_);$_.="\n"'
Decodiert werden sie so:
echo "=?UTF-8?B?5Pb8LmV4ZQ==?=" |
perl -MMIME::Words=:all -pe '$_=decode_mimewords($_)'
Angeregt durch sendxmpp habe ich mich mal an einem eigenen Perl-Script versucht, das Jabber-Nachrichten versenden kann. Da sendxmpp selbst in Perl geschrieben ist, war das natürlich keine allzugroße Kunst und somit ein kleines Spielscript schnell in ein paar Zeilen runtergeschrieben: jabber-send.pl
Net::XMPP und seine Subklassen sind leider nicht wirklich lustig. Eine Fehlerbehandlung war nur durch Trial-and-Error umsetzbar, und an der Aufgabe, vor dem Senden festzustellen, ob der Empfänger überhaupt online ist (das war Sinn der Übung, sonst hätte ich bei sendxmpp bleiben können) bin ich gescheitert, da ich mangels Protokollkenntnis die Doku nicht verstanden habe. Irgendwie eine unbefriedigende Angelegenheit.
Nach längerer Abstinenz habe ich heute mal wieder einen dieser liederlichen Perl-Einzeiler verbrochen. $KUNDE wollte aus Webserver-Logs die IP-Adressen entfernen, aber für die weitere Auswertung sollten die Clients doch noch unterscheidbar sein.
perl -ape '$i=167772161;unless($f{$F[0]}){$o++;while((0==($i+$o)%256)or
(0==($i+$o+1)%256)){$o++};$f{$F[0]}=join(".",unpack("C4",pack("N",$i+$o)))}
s/$F[0]\b/$f{$F[0]}/' < /blah/blubb/access_log
