nicht angemeldet
Probleme bei lokaler Version und Serverversion???
Hallo Leute,
Ich teste meine Perl-Scripts lokal (wie wahrscheinlich alle hier) auf meinem Rechner (Xitami-WebServer, WINDOW-Perl). Leider musste ich feststellen das ich meine lokale Version in den seltensten Fällen auf Anhieb oder überhaupt nicht unter UNIX laufen ( selbstverständlich unter Anpassung der Pfadangabe., etc.), NT-Server bereiten keine Problem.
Hier meine Frage, woran liegt das? Gibt es verschieden PERL-Versionen? Kann es an Sicherheitsanstellungen liegen? Gibt es Möglichkeiten eine UNIX-Server möglichst genau unter Windows zu simulieren (wird nämlich langsam lästig)?
Beste Grüsse
Neuberg
-
Hallo Rüdiger,
es gibt da 2 Probleme, die ich auch schon hatte.
1. Hast Du dein FTP-Programm auf Textübertragungeingestellt ?, das ist wichtig, da unter Unix ein Ascii-Text andere Seitenumbruchzeichen hat, im Textmodus ersetzt das FTP Programm die Zeilenumbrüche entsprechend.
2. Ich hatte mal ein Problem mit dem Header, der Header muss unter Unix mit \n\n beendet werden, ich glaube ohne weitere Leerzeichen in der Zeile, die Perlinterpreter unter Windows scheinen da etwas liberaler zu sein.
Gruss
MArko
-
Gibt es verschieden PERL-Versionen? Kann es an Sicherheitsanstellungen liegen? Gibt es Möglichkeiten eine UNIX-Server möglichst genau unter Windows zu simulieren (wird nämlich langsam lästig)?
Ja, natürlich gibt es verschiedene Perl-Versionen. Wenn Du einen telnet- oder rlogin-Zugang zu Deinem CGI-Server hast, dann gib mal "perl -v" ein, das wird Dir die Perl-Version anzeigen.
Allerdings sollten alle Perl-Versionen ab 5 aufwärts bezüglich der Basis-Syntax hinreichend kompatibel sein. (Neulich mußte ich ein Perl5-Skript unter einem Subset von Perl4 laufen lassen und bin fast gestorben dabei: Das kannte weder "my" noch Prozedurprototypen oder "use strict" ...)
Was eher vorkommen kann, ist, daß irgendwelche Module nicht da sind, weil es Perl in verschiedenen Ausbaustufen gibt und beispielsweise ActivePerl 5.005build509 wesentlich mehr Module bereitstellt als Perl5004_002 von Larry Wall.
Das kann man ggf. durch entsprechend defensive Programmierung abfangen und dann wenigstens eine Fehlermeldung ausgeben.Es ist aber wesentlich wahrscheinlicher, daß Probleme bei CGI-Skripts an Einstellungen des Webservers, an Dateizugriffsrechten, an binärer Übertragung der Skripts etc. liegen.
Ich glaube, wir sollten wirklich mal einen Artikel über das Testen von CGI-Anwendungen schreiben - das ist hier ja ein echter Dauerbrenner ...