Wenn diese Nachricht wahr ist kann ich den Feed wohl bald aus meinem Reader löschen. Schade drum, Mark hat einige wirklich coole Projekte gemacht. 
BTW: Wenn es wahr ist, hat er während des Radfahrens eine Herzattacke erlitten. In dem Artikel bei Make hätte man durchaus ein anderes Projekt als Beispiel einbauen können als den Bicycle iPod Charger…
Edit: Ist wohl tatsächlich wahr.
Wie schon erwähnt muss ich mich bei der Arbeit mit Windows rumschlagen. Um Sehnenscheidenentzündungen vorzubeugen verschlägt es mich da bisweilen auch in die Kommandozeile. OK, das ist nicht der einzige Grund. Manchmal will man ja aus einem Skript (leider in diesem Fall kein Perl) heraus einfach mal ein system() aufrufen, und da muss man dann halt DOS-Kommandos absetzen.
Jetzt wollte ich etwas kluges basteln, das testet ob ich eine Datei (schreiben|lesen|löschen) kann. Auf anderen Systemen hätte ich dazu auf etwas in der Form
kommando; echo $?
gesetzt, die Ausgabe könnte ich parsen. Ein Kollege hat für DOS
kommando && echo ok || echo nein
vorgeschlagen, das sollte funktionieren. Prima, Exitcodes kann ich dann offenbar auswerten. Oder?
Um Vielleicht mehr Infos zu kriegen als (tut’s|tut’s nicht) versuche ich folgendes:
kommando & echo %ERRORLEVEL%
Und jetzt bin ich verwirrt (siehe Screenshot):
Das mit && funktioniert scheinbar, die Ausgabe von %ERRORLEVEL% bringt aber nicht sinnvolles? Was wird denn dann von && bzw. || ausgewertet? Und wie zur Hölle kriege ich den wirklichen Exit-Code?!?
Nach etwas mehr Spielerei stelle ich fest, dass in einigen Konstellationen der %ERRORLEVEL% tatsächlich gesetzt wird. Leider immer ein Kommando zu spät, wie man am zweiten Screenshot erkennen kann. Komischerweise funktioniert das aber — wenn man da von ‚funktionieren‘ sprechen kann — auch nur bei Programmaufrufen.
echo > . & echo %ERRORLEVEL%
führt zwar jedes Mal zu einer Fehlermeldung, gibt aber trotzdem nur 0 aus…
Ich beschließe einfach erstmal, das nicht zu verstehen. Mein eigentliches Problem kann ich offenbar unter Windows nicht elegant lösen, also muss ich mir da was anderes ausdenken…
Im Moment bin ich wie schon erwähnt dazu gezwungen, beruflich viel auf Windows zu machen. Leider knirscht es dabei an allen Ecken und Enden, wenn man wie gewohnt produktiv sein will. Eine Menge Werkzeuge fehlen einfach, mal eben schnell eine elegante Shell- oder Perl-Zeile abschicken geht nicht. Von ganzen Skripten ganz zu schweigen.
Klar gibt es mit Cygwin oder ActiveState auch die Möglichkeit, einen Werkzeugkasten auf Windows nachzuinstallieren. Aber das ist lästig, und das würde ich auch nicht auf hunderten produktiver Server bei meinem aktuellen Kunden machen wollen. Geschweige denn: dürfen.
Ich habe jetzt eine Lösung gefunden die zwar kein hundertprozentiger Ersatz für eine anständige Umgebung ist, aber die an einigen Stellen schon echt hilfreich war: PAR::Packer.
Auf meinem Arbeitsplatz habe ich ein ActiveState-Perl installiert, darin das genannte Modul. Jetzt kann ich beispielsweise folgendes eingeben:
pp -e "print time();"
Die Maschine kaut eine Weile auf dem Kommando rum und spuckt dann eine a.exe aus, die ab sofort den aktuellen Unix-Timestamp ausspuckt wenn man sie aufruft. Und das auch auf Systemen auf denen keine Perl-Umgebung installiert ist, man braucht also keine zusätzlichen DLLs oder so, nur die jeweilige EXE.
Leider ist es nicht so, dass pp das Kommando wirklich compiliert. Es ist vielmehr so, dass pp ein Archiv zusammenpackt in dem alles drin steckt was zur Ausführung des Befehls nötig ist. Die Ausgabe des entstehenden Executables ist zwar die gleiche, aber oben genanntes a.exe ist 1.844.011 Bytes groß und braucht auf meiner Kiste über eine Sekunde bevor sie wirklich ausgeführt wird. Klar, muss ja erst entpackt werden.
Die gute Nachricht ist, dass lediglich der Start so lange dauert. Das enthaltene Programm läuft — nach dem Entpacken — praktisch genauso schnell wie in einer ‚richtigen‘ Perl-Umgebung.
Wer es etwas schicker haben will kann übrigens auch direkt folgendes machen:
pp --output=timestamp.exe -e "print time();"
Und komplexe Skripte werden wie folgt gepackt:
pp --output=weltherrschaft.exe weltherrschaft.pl
Die Größe der entstehenden Datei steigt übrigens nicht derartig an dass für jede Zeile wieder 1,8MB dazu kommen. Ich habe hier ein Skript von 5.308 Bytes übersetzt, das EXE ist 2.493.292 Bytes groß. Immer noch eine Menge, aber für einen schnellen Hack ist das durchaus tauglich.
Tja, alberne Materie gibt es nicht mal bei Wikipedia. Warum eigentlich nicht? Falls irgendein Physiker dies liest bitte ich ihn hiermit förmlich, an den Namen zu denken wenn er irgendwann mal was vor sich hat das keinen Namen hat. Dunkle Materie, Seltsame Materie und Exotische Materie gibt es schließlich auch… 
Egal, ich mach mir jetzt noch einen Quarkstern mit Zimt, und dann muss ich schlafen gehen… dringend, wie mir scheint… 
… aber deshalb gleich Anti-Terrorismus-Gesetze anwenden ist übertrieben. Pfui!
… zum Beispiel noch nicht wie angekündigt mein letztes Mikrocontroller-Projekt zu veröffentlichen, die meisten davon sind nicht so schön: Allgemeines Plattensterben zum Beispiel.
Meine Notebook-Platte ist komplett abgeraucht. Das Backup war zwar ein halbes Jahr alt, aber die wichtigsten Änderungen habe ich in der Versionsverwaltung gehabt. Auf einem anderen Rechner. Nachdem die 20GB im Notebook tot waren habe ich die 80GB aus dem MP3-Player da rein gebaut. Der Player hat dann eine 160er Platte bekommen die hier schon bereit lag. Nicht weil ich da so viel Platz brauche, sondern einfach weil’s geht (Zugegeben, nicht vollständig. Aber 160GB stecken da jetzt drin.).
Dann habe ich meinen Server hier zu Hause in ein anderes Gehäuse gebaut. Bislang war das ein einfacher Mini-Tower der früher unter irgendeinem Schreibtisch gestanden hat. Jetzt steckt er in einem stattlichen 19″-Gehäuse und beschallt den Schrank im Keller. Das wäre eine kleine Bastelei gewesen, wenn dabei nicht auch wieder eine Platte gestorben wäre. Übergangsweise habe ich die durch eine aus dem RAID ersetzt, aber das ist kein Dauerzustand. Und da ich das jetzt richtig ordentlich machen wollte habe ich direkt ein komplett neues RAID aufgebaut. Auf Dauer sollen in der Kiste drei 500er SATA-Platten werkeln, als Software-RAID5. Also mit insgesamt 1GB 1TB (natürlich, Danke Jürgen ) Platz, darauf dann ein LVM und dann die Daten. Hauptsächlich ist das Platz fuer Backups und VDR-Aufnahmen. Das neue RAID tut so auch schon, aber die Kiste kann nicht von SATA booten. Also kommt die /boot-Partition auf eine CF-Karte an IDE, damit nicht noch eine Platte laufen muss. Um das zu machen will ich vorher einen anständigen Kernel haben, und so kommt man vom hundertsten aufs tausendste…
Momentan läuft da noch ein 2.6.11, den ich 2005 mal mit Xen-Unterstützung gebacken hatte. Mittlerweile kann Debian ab Werk Xen, und 2.6.18 klingt auch deutlich weniger antik (Naja… relativ). Jetzt lautet das Stichwort aber: Upgradepfad. Und da hakt es, weil ich damals froh war das Xen überhaupt zum Rennen gekriegt zu haben. Um Pakete habe ich mich nicht gekümmert, und das beißt sich jetzt natürlich mit den Debian-Paketen. Der erste Versuch Gestern Abend ist gründlich in die Hose gegangen, da musste ich zurückrudern. Jetzt liegt wohl RTFM an…
Ach ja, und wenn das alles erledigt ist kümmere ich mich auch wieder um das angesprochene Projekt. Veröffentlicht wird das auf jeden Fall noch.
Preisspanne? Preispanne? Wie auch immer: Augen auf beim Hardwarekauf! 
Wow, ich hätte nicht gedacht dass ein einfacher ATmega168 mit 19,6608MHz dazu in der Lage ist. Ich bin beeindruckt!
… man kann noch so lange an einem Problem rum programmieren, einen kaputten Stecker kann man nicht wieder heil programmieren. Auch nicht wenn man da einen kompletten Samstag reinsteckt.
Aber der One-Wire-Bus ist an der Stelle auch echt ein Arsch. Wer ihn nicht kennt: der Name ist etwas verwirrend. Zwei Drähte braucht man mindestens: einen für die Masse, einen für Daten. Eine Versorgungsspannung kann man wenn man möchte zusätzlich anlegen. Wenn man das nicht machen will kann man die Bausteine auf dem Bus — Temperaturfühler in meinem Fall — auch über die Datenleitung mit Saft versorgen. Eigentlich muss man dazu dann noch einen zusätzlichen FET benutzen.
Der Samstag hat mir aber gezeigt, dass es auch ohne den FET geht, wenn zum Beispiel der Pin für die Versorgungsspannung im Stecker kaputt ist. Und wenn man mehrere Sensoren auf dem Bus hat gibt es sehr merkwürdige Ergebnisse, empfehlenswert ist das also nicht. Das doofe ist: es gibt Ergebnisse. Wenn gar nichts geht kommt man schnell auf die Idee zu messen. Wenn aber der Bus die Geräte sieht, diesen aber keine Ergebnisse entlocken kann, ist das… irreführend.
Naja: Gefahr erkannt, Gefahr gebannt. Heute habe ich mein aktuelles Mikrocontroller-Projekt in Betrieb genommen. Ein Gehäuse fehlt noch, dann mache ich ein paar Fotos und veröffentliche es. Vielleicht auch ohne Gehäuse, dann wird das diese Woche noch was.