Schlagwort: Perl

Net::SSLeay: load_file:Das angegebene Modul wurde nicht gefunden

· · 0 Kommentare

Der Versuch, das Perl-Modul "WWW::Mechanize" zu installieren scheitert mit der Meldung, daß ein Modul nicht gefunden werden kann:

cpan> install WWW::Mechanize
...
Can't load 'C:/Strawberry/perl/vendor/lib/auto/Net/SSLeay/SSLeay.xs.dll' for module Net::SSLeay: load_file:Das angegebene Modul wurde nicht gefunden at C:/Strawberry/perl/lib/DynaLoader.pm line 193.
  at C:/Strawberry/perl/vendor/lib/IO/Socket/SSL.pm line 19.
...
Can't load 'C:/Strawberry/perl/vendor/lib/auto/Crypt/SSLeay/SSLeay.xs.dll' for module Crypt::SSLeay: load_file:Das angegebene Modul wurde nicht gefunden at C:/Strawberry/perl/lib/DynaLoader.pm line 193.
  at C:/Strawberry/perl/vendor/lib/Net/SSL.pm line 20.
...

Die ausgegebene Fehlermeldung führt allerdings zuerst auf eine falsche Fährte, denn in angegebenen Ordnern ist das Modul sehr wohl zu finden:

C:\>dir C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay\SSLeay.xs.dll
...
 Verzeichnis von C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay

17.03.2020  05:24           485.888 SSLeay.xs.dll
...

C:\>dir C:\Strawberry\perl\vendor\lib\auto\Crypt\SSLeay\SSLeay.xs.dll
...
 Verzeichnis von C:\Strawberry\perl\vendor\lib\auto\Crypt\SSLeay

17.03.2020  05:26            59.904 SSLeay.xs.dll
...

Die Ursachenforschung im Internet führt überwiegend zu Treffern, die darauf hin deuten, daß ein Problem mit Modulabhängigkeiten besteht und überprüft werden sollte, ob der der Ordner "C:\Strawberry\c\bin" im Pfad enthalten ist. Dies ist der Fall:

Path=...;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;

Eine Analyse mit Microsofts Process Monitor zeigt, daß es an insgesamt drei Modulen aus dem Ordner "C:\Strawberry\c\bin" liegt, die trotz vorhandenem Pfad-Eintrag nicht gefunden werden.

 

Zum Beheben des Fehlers können entweder die drei Module in den Ordner "C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay\" kopiert oder (als vielleicht elegantere Lösung) entsprechende Links gesetzt werden:

C:\>cd C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay\

C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay>mklink libcrypto-1_1-x64__.dll C:\Strawberry\c\bin\libcrypto-1_1-x64__.dll
symbolische Verknüpfung erstellt für libcrypto-1_1-x64__.dll <<===>> C:\Strawberry\c\bin\libcrypto-1_1-x64__.dll

C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay>mklink libssl-1_1-x64__.dll C:\Strawberry\c\bin\libssl-1_1-x64__.dll
symbolische Verknüpfung erstellt für libssl-1_1-x64__.dll <<===>> C:\Strawberry\c\bin\libssl-1_1-x64__.dll

C:\Strawberry\perl\vendor\lib\auto\Net\SSLeay>mklink zlib1__.dll C:\Strawberry\c\bin\zlib1__.dll
symbolische Verknüpfung erstellt für zlib1__.dll <<===>> C:\Strawberry\c\bin\zlib1__.dll

Anschließend läuft die Installation ohne Probleme durch:

cpan> install WWW::Mechanize
...
All tests successful.
Files=62, Tests=816, 147 wallclock secs ( 0.23 usr + 0.19 sys = 0.42 CPU)
Result: PASS

Selbstrettung

· · 0 Kommentare

Nach dem Umzug eines Perl-Skripts auf einen neuen Host lief das Skript auf den Fehler

No type library matching "Microsoft Outlook" found"

obwohl alle benötigten Module installiert waren.

Die befragte Suchmaschine lieferte als erstes Ergebnis meinen eigenen Blogbeitrag "No type library matching "Microsoft Outlook" found". Offensichtlich hatte ich den Fehler vor rund 4 1/2 Jahren schon einmal.


Windows-Hintergrundbild mit Perl setzen

· · 0 Kommentare

Das Setzen des Windows-Hintergrundbilds ist von Perl aus ganz einfach - zumindest wenn man die Win32-API verwendet:

use strict;
use warnings;
use Win32::API;

use constant SPI_SETDESKWALLPAPER => 0x0014;
use constant SPIF_UPDATEINIFILE   => 0x0001;
use constant SPIF_SENDCHANGE      => 0x0002;
use constant ZERO                 => 0x0000;

my $syspinf = Win32::API->new('user32', 'SystemParametersInfo', [I,I,P,I], I) or die "SystemParametersInfo not available.\n";

$syspinf->Call(SPI_SETDESKWALLPAPER, ZERO, $ARGV[0], SPIF_UPDATEINIFILE | SPIF_SENDCHANGE);

Das Skript erwartet den Namen des Bildes inklusive Pfad als Parameter.


LDAP-Suche schlägt bei Namen mit Umlauten fehl

· · 0 Kommentare

Solange ein Benuztername keinen Umlaut besitzt, kann man den Datensatz Daten mit dem Perl-Modul Net::LDAP recht einfach aus dem Active Directory auslesen:

use Net::LDAP;
$loginUser = Win32::LoginName();

$ldap = Net::LDAP->new($ldapServer) or die "$0";
$ldap->bind($ldapUser, $ldapPass});
$ldap_base = 'OU=Users';
$ldap_results = $ldap->search(base => $ldapBase, filter => "sAMAccountName=$loginUser");

if ($ldap_results->count) {
    # was ganz tolles mit dem Datensatz anstellen
}

Sofern aber ein Umlaut in dem Login-Namen steckt, so schlägt die Suche nach "benjamin.tröt" fehl, obwohl ein entsprechender sAMAccountName im Active Directory vorhanden ist.

Eine einfache Lösung bietet der Beitrag "Windows logon behavior if your user name contains characters that have accents or other diacritical marks", welcher - auf das Login bezogen - folgende Ausweichmöglichkeit skizziert:

If your user name in the Active Directory directory service contains one or more characters that have accents or other diacritical marks, you may find that you do not have to use the diacritical mark as you type your user name to log on to Windows. You can log on by using the simple form of the character or characters. For example, if your user name in Active Directory is jésush, you can type jesush in the User name box in the Log On to Windows dialog box to log on to Windows.

Interessanterweise funktioniert dies auch bei LDAP-Anfragen im Active Directory, so daß eine Suche nach dem sAMAccountName "benjamin.trot" zum gewünschten Datensatz führt.

Stellt sich die Frage, was passiert, wenn tatsächlich ein Benjamin Trot neben seinem Kollegen Tröt Platz nimmt ...


Firefox ignoriert charset=UTF-8

· · 0 Kommentare

Ein Perl-Skript stellt sein UI als Website mit Hilfe des Moduls HTTP::Server::Simple zur Verfügung. Eigentlich sollte ein

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

im Header-Bereich ausreichen, um anzuzeigen, daß die Daten in UTF-8 kodiert sind. Firefox weigerte sich hartnäckig und benutze immer den Default "windows-1252" zur Darstellung, was alle Umlaute bis zur Unkenntlichkeit verstümmelte.

Erst durch Mitsenden der Zeichenkodierung im Header

print $cgi->header(
	-nph => 1,
	-status => '200 OK',
	-type => 'text/html',
	-charset => 'UTF-8'
);

ließ sich Firefox überreden, die Seite auch tatsächlich als UTF-8 darzustellen.