Um ein Perl-Skript portabel zu machen, muß zusammen mit dem Skript auch die Perl Laufzeitumgebung sowie die benötigten Bibliotheken ausgeliefert werden.

Befragt man die Suchmaschine der Wahl, landet man meist bei der Empfehlung, einen Perl-Packer zu nehmen, von denen es im CPAN zwei Stück gibt: PAR-Packer und perlcc, wobei von der Verwendung von perlcc im produktiven Umfeld ganz klar abgeraten wird: “Use for production purposes is strongly discouraged.”.

Mit pp gibt es ein eigenes Skript, auf Basis von PAR ausführbare Dateien erzeugt und ein Skript mitsamt aller benötigter Bibliotheken in einer einzelnen .EXE-Datei verpackt.

Das Packen ist recht flexibel und schnell erledigt, die einzelnen Optionen können in der Dokumentation nachgeschlagen werden.

Wer noch gerne ein schöne(re)s Icon für die erzeugte .EXE-Datei verwenden möchte, kann dies mit einem Einzeler hinzufügen:

Als Ergebnis wird eine Datei “test.exe” erzeugt, die dann auf ein System ohne Perl-Laufzeitumgebung kopiert und dort ausgeführt werden kann. Die Beschreibung “perlcc that works without hassle” klingt erstmal gut und die Ergebnisse funktionieren, bringen aber leider in der Anwendung einige Probleme mit sich:

Technisch gesehen wandelt pp nicht wirklich das Skript in eine .EXE-Datei, sondern erzeugt ein selbstenpackendes Archiv, dessen Inhalt nach dem Entpacken letztendlich ausgeführt wird. Das Archiv wird standardmäßig ins TEMP-Verzeichnis des ausführenden Benutzers entpackt, was spätestens dann zu Problemen führt, wenn - aus guten Grund - unprivilegierten Benutzern das Ausführen von Code innerhalb des TEMP-Verzeichnis verboten ist.

Zum Entpacken wird ein Verzeichnis nach dem Muster “%TEMP%\par-USER\cache-GUID” angelegt, wobei USER durch eine Hex-Repräsentation des ausführenden Benutzers und GUID durch einen Hash der ausführbaren Datei ersetzt wird. Letzteres lässt sich mit Hilfe des Parameters “-T” durch einen festen Wert ersetzten, so daß der Pfad dann “%TEMP%\par-USER\cache-test” lautet.

Durch das Cachen der entpackten Dateien wird bei späteren Starts die Wartezeit deutlich verkürzt, je nach System und Anzahl der Benutzer können aber zahlreiche Dateileichen im Temp-Verzeichnis verbleiben.

Manuelle Paketierung

Abgesehen von der suboptimalen Ausführung erledigt pp das Sammeln aller benötigter Dateien sowie Erstellen des Pakets zuverlässig, so daß sich die Verwendung von pp als Zwischenschritt zum manuellen Packen anbietet.

Nach dem erstmaligen Ausführen der von pp erzeugten Datei werden folgende Inhalte des Verzeichnisses “%TEMP%\par-USER\cache-test” in ein Arbeitsverzeichnis kopiert:

• der komplette Ordner “inc” inklusive aller darin enthaltenen Unterverzeichnisse
• die Dateien “libgcc_s_seh-1.dll”, “libstdc++-6.dll”, “libwinpthread-1.dll” sowie “perl530.dll”

Anschließend kann noch etwas augeräumt werden:

• im Ordner “inc” können die Dateien “MANIFEST” sowie “META.yml” gelöscht werden
• im Ordner “inc/script” kann die Datei “main.pl” gelöscht werden

Zum Ausführen müssen aus der Perl-Installation noch zwei Dateien kopiert werden:

• die Datei “perl.exe” oder “wperl.exe” aus dem Ordner “perl/bin” ins Arbeitsverzeichnis - je nachdem, ob es sich um eine Kommandozeilen- oder GUI-Anwendung handelt
• die Datei “lib.pm” aus dem Ordner “perl/lib” in den Ordner “inc/lib”

Anschließend kann aus dem Ordner “inc” das Skript mit folgendem Aufruf gestartet werden:

Im Laufe der Jahre hat sich die Anzahl der von mir betreuten Joomla!-Installationen deutlich reduziert. Von mehreren Websites ist noch eine Intranet-Seite übriggeblieben, welche bis vor Kurzem noch mit Joomla! 3 lief.

Hauptgrund hierfür war die aus meiner Sicht nur spärlich vorhandene Dokumentation für Entwickler, welche Anpassungen an Erweiterungen bei Versionsänderungen zu machen sind. Während zum Beispiel der Wechsel zu Hugo auf Grund der guten Dokumentation in Kombination mit einem ebenso guten Forum nur wenig Frustmomente bot, war schon die Erfahrung beim Umstieg von Joomla! 1.5 auf 2.5 derart nervig, daß im Laufe der Zeit alle Websites von Joomla! zu WordPress migriert wurden, statt den Versuch zu starten, die bestehende Funktionalität unter der neuen Joomla!-Version lauffähig zu bekommen.

Nachdem inzwischen aber Joomla! 5 veröffentlicht ist, sollte auch die Intranet-Site zumindest auf Joomla! 4 migriert und somit auch die selbstentwickelten Erweiterungen angepasst werden, was sich wieder als frustrierendes Erlebnis entpuppte. Wenn es schon Zusammenstellungen wie “Potential backward compatibility issues in Joomla 4” gibt, wäre es hilfreich, wenn dort nicht als erstes ein “Content is Incomplete” ins Auge springen würde und viele der hier aufgelisteten Dinge auch dort zu finden wären.

In diesem Beitrag habe ich die verschiedenen Quellen gesammelt, mit denen ich die Erweiterungen mit Joomla! 4 lauffähig gemacht habe - am Ende des jeweiligen Abschnitts ist als Quelle die Seite angegeben, auf welcher ich als erstes auf meiner Suche nach Lösungen fündig wurde. Vieles davon ist sog. Legacy-Funktionalität, d.h. ich habe nicht nach aktueller Philosophie neu entwickelt, sondern versucht, mit minimalem Aufwand die jeweilige Erweiterung zu reparieren und wieder funktionsfähig zu bekommen.

Weiterlesen

Nach dem Wechsel des Reverse-Proxys war ein mit HTTP::DAV arbeitendes Perl-Skript nicht mehr in der Lage, Daten abzurufen. Die Fehlermeldung war alles andere als aussagekräftig:

Auch eine Erhöhung des DebugLevels von 0 (“off”) auf 3 (“noisy”) brachte keine weiteren Erkenntnisse, so daß manuelle Fehlersuche angesagt war. Da weder am Server noch am Skript Änderungen vorgenommen wurden, konzentrierte sich die Suche auf den Reverse-Proxy

Letztendlich lag der Fehler an einem fehlenden Intermediate-Zertifikat des Trustcenters auf dem Reverse-Proxy. Nach dem Hinzufügen des fehlenden Zertifikats funktionierten die Zugriffe wieder wie erwartet.

Nachdem mit Hilfe des XUM 1541-Adapters die Originalmedien als D64-Images auf dem PC gesichert wurden, steht als nächstes das Auslesen der auf den Disketten befindlichen Dateien an. Es gibt hierzu eine ganze Reihe von Programmen, mit am einfachsten ist wohl das mit dem VICE-Emulator mitgelieferte Kommandozeilenprogramm “c1541”, welches die Aufgabe in einer Zeile erledigt:

Der Spaß am C64 war aber schon immer das Basteln und so war es naheliegend, selbst ein Programm zum Auslesen zu schreiben, dabei etwas Retro-Luft zu schnuppern und längst verblasstes Halbwissen aufzufrischen.

Weiterlesen

Eine selbsterstellte Erweiterung für die GNOME Shell funktionierte zwar einwandfrei, allerdings beschwerte sich der Dconf-Editor, daß die Konfigurations-Schlüssel trotz vorhandenener “schema”-Datei im Erweiterungsordner nicht von einem Schema definiert würden.

Beim Klick auf einen Schlüssel wurde zusätzlich eine erweiterte Fehlermeldung angezeigt:

Kein Schema verfügbar. Ein Schema beschreibt die Verwendung eines Schlüssels und Dconf-Editor kann kein Schema finden, das diesem Schlüssel zugeordnet ist.

Zur Lösung des Problems half ein Blick in die Dateiliste einer mit Debian mitgelieferten Erweiterung wie z.B. “Dash to Dock”

Offensichtlich müssen die “schema”-Dateien in einem gesonderten Verzeichnis gespeichert werden. Für eine im Benutzerkontext installierte Erweiterung ist dies der Ordner “~/.local/share/glib-2.0/schemas” statt dem Systemordner “/usr/share/glib-2.0/schemas”

Nach dem Anlegen des Ordners und dem Kopieren der Schema-Datei (wahlweise funktioniert auch das Setzen eines symbolischen Links) muß die Schema-Datei noch kompiliert werden, dann ist auch der Dconf-Editor zufrieden.

RTFM hätte hier auch ohne den Umweg über eine andere Erweiterung geholfen, denn die Hilfeseite zu “glib-compile-schemas” verrät bereits:

The usual location to install schema files is /usr/share/glib-2.0/schemas.