wunderlicher 500er Fehler - bereits gelöst

[Johnny B.]

Nun wird's grenzwertig:

ich habe zwei Scripte, beide exakt gleich:

#!/usr/bin/perl -w
print "Content-type: text/html\n\n";
print "Hallo!";

Beide im selben Editor.

Lade ich das eine per FTP hoch, kommt ein 500er Fehler. CHMOD ist 755, ASCII-Übertragung.
Lade ich das andere mit demselben Namen und demselben Editor genauso hoch, funktioniert es.

Bin ich denn bescheuert? Die Dateien sind gleich, der Übertragungsweg ist gleich, die Rechte sind gleich, sogar der Dateiname auf dem Server ist gleich - und doch: wenn ich das eine test.pl per FTP speichere, kommt der 500er Fehler. Im error.log ist allerdings kein Fehler vermerkt. Über CPU und Memory-Ressourcen brauch ich bei dem Script nicht nachdenken. What the heck?

Ich glaub's nicht, und doch kann ich es immer wiederholen: lade ich das Script vom linken Reiter hoch, 500er Fehler. Rechter Reiter: geht.

In der HEX-Darstellung sind beide Dateien 100% gleich.

<lange pause, furchen am kopf vom kratzen>

AAAaaaaaaahhh, Moment: jetzt ich sehe einen Unterschied: unten im Editor steht einmal "MAC" und einmal "DOS". Verflucht...

Da habe ich wohl unabsichtlich mit der Maus draufgeklickt. TOLL!

Mein Script lief nicht mehr und ich kreise den Fehler immer weiter ein, bis ich bei den beiden "magischen" test.pl lande und kurz davor stehe, an meinem Verstand zu zweifeln. Dann sowas...

Also falls irgendwer irgendwann mal unerwartete 500er Fehler im laufenden Betrieb feststellt - alles hat eine Ursache, auch wenn manche schwierig zu entdecken sind.

Mindboggelige Grüße
Johnny

[Beat]

AAAaaaaaaahhh, Moment: jetzt ich sehe einen Unterschied: unten im Editor steht einmal "MAC" und einmal "DOS". Verflucht...

Da habe ich wohl unabsichtlich mit der Maus draufgeklickt. TOLL!

Also falls irgendwer irgendwann mal unerwartete 500er Fehler im laufenden Betrieb feststellt - alles hat eine Ursache, auch wenn manche schwierig zu entdecken sind.

Du solltest den Unterschied im Script beschreiben. Nicht die Aktion, welche den Unterschied erzeugt hat.

Ich vermute, die Scripte unterscheiden sich bezüglich UTF-8 ohne BOM versus UTF-8 mit BOM
Die BOM macht ein Script unausführbar, weil nun mal das erste Zeichen eines CGI-Scripts #! gefolgt von einem Pfad zum Interpreter sein muss

mfg Beat

[Johnny B.]

Du solltest den Unterschied im Script beschreiben. Nicht die Aktion, welche den Unterschied erzeugt hat.

Ich vermute, die Scripte unterscheiden sich bezüglich UTF-8 ohne BOM versus UTF-8 mit BOM
Die BOM macht ein Script unausführbar, weil nun mal das erste Zeichen eines CGI-Scripts #! gefolgt von einem Pfad zum Interpreter sein muss

--- in meinem Editor (Ultra-Edit) sind beide Scripte exakt gleich dargestellt. Ich hab's mir auch in der HEX-Ansicht angeschaut. Beide Scripte sind 72 Zeichen groß. Keinerlei Unterschied sichtbar - außer dem "MAC" bzw. "DOS" unten mittig in der Statusleiste. Ich habe in dem anderen Editor (PSPad) eine Datei editiert und dort steht ebenfalls unten "MAC" oder "DOS" und dort kann man durch Anklicken hin- und herwechseln. Wenn dieser Unterschied BOM sind, sind sie unsichtbar. Ich habe mir auf meiner Suche nach irgendeinem Unterschied zwischen diesen beiden Dateien auch die "Nicht druckbaren Zeichen" anzeigen lassen. Auch hier zeigen sich beide Scripte exakt gleich. Trickreiche Geschichte. Im Nachhinein ist es dann lustig... <grmpflx>

[Beat]

Beide Scripte sind 72 Zeichen groß. Keinerlei Unterschied sichtbar - außer dem "MAC" bzw. "DOS" unten mittig in der Statusleiste.

Auf dieser Seite
http://www.elcappuccino.ch/ehome-factory/perl
ganz unten findest du ein Perl-Script, dass einen MD5 Digest von einem File berechnet und als HEX String ausgibt.
Zwei identische Files erzeugen zwei identische Digests.
Der kleinste Unterschied erzeugt komplett verschiedene Digests.

mfg Beat

[hotti]

moin,

--- in meinem Editor (Ultra-Edit) sind beide Scripte exakt gleich dargestellt. Ich hab's mir auch in der HEX-Ansicht angeschaut. Beide Scripte sind 72 Zeichen groß. Keinerlei Unterschied sichtbar - außer dem "MAC" bzw. "DOS" unten mittig in der Statusleiste.

Mit Letzterem zeigt ja Dein Editor den Unterschied beider Scripte an. Ein Editor ist wie eine Brille an deren Rand Notizen sind. Zum (doofen) Vergleich:

Schreibe einen Text mit MSWord und speichere die Datei ab. Verändere den Text nicht, aber speichere mehrmals ab mit der Option "Schnellspeichern zulassen". Zwischenzeitlich notiere die Anzahl der Zeichen - sie wird sich nicht veränderen. Aber wenn Du hintenrum mal die Datei betrachtest, wirst Du sehen, das die immer größer wird mit jedem Speichervorgang.

Und was lernen wir daraus!? MSWord zeigt nur das, von dem die Programmierer dachten, dass es das ist, was der Benutzer sehen will.

Sch?ne Gr??e,
Horst Klugschei?er

[Johnny B.]

Und was lernen wir daraus!? MSWord zeigt nur das, von dem die Programmierer dachten, dass es das ist, was der Benutzer sehen will.

--- ist an sich mal 'ne feine Idee: mit MSWord als Editor zu programmieren... *ggg*

Ich habe jetzt die beiden Versionen des Scripts abgespeichert:

• die DOS-Version hat 73 Bytes
• die MAC-Version hat 71 Bytes
• die MS-Word-Version bringt es aus dem Stand auf 24.064 Bytes...

Ich war aus früheren C-64-Assembler und Maschinensprache-Tagen bisher fest davon ausgegangen, daß ein Texteditor keine Randnotizen geheim hält, sondern ALLE Zeichen anzeigt. So wie die Datei aufgebaut ist, egal was für Zeichen: Sonderzeichen, Steuerzeichen; jedes Byte wird angezeigt. Die 2 Bytes (BOM?), die die DOS-Version mehr hat, zeigt mir mein Editor nicht an. Weder Ultra-Edit noch PSPad. Geheimnistuerei in Text-Editor-Kreisen. Das prangere ich an!

Immer noch verwirrte Grüße
JOhnnY

[Der Martin]

Hallo,

--- ist an sich mal 'ne feine Idee: mit MSWord als Editor zu programmieren... *ggg*

naja, dann kannste dir dein Syntax-Hilighting mit statischer Formatierung selbst machen. ;-)

Ich habe jetzt die beiden Versionen des Scripts abgespeichert:

• die DOS-Version hat 73 Bytes

Zeilenumbrüche CR/LF (0x0D, 0x0A).
Interessant: Wenn ich das Beispielscript aus deinem Originalposting im DOS/Windows-Format speichere, bekomme ich eine Datei mit 75 Bytes (3 Zeilen mit 18, 36 und 15 Nutzzeichen, 3 Zeilenenden à 2 Byte). Oder hast du das CR/LF der letzten Zeile weggelassen? - Dann käme ich auch auf 73.

• die MAC-Version hat 71 Bytes

Zeilenumbrüche nur CR (0x0D).
Damit komme ich auf 72 Zeichen (oder 71 wie du, wenn ich das CR der letzten Zeile weglasse).

• die MS-Word-Version bringt es aus dem Stand auf 24.064 Bytes...

Na klar. Word speichert ja auch die komplette Formatierung und einen Haufen von Metainformationen.

Ich war aus früheren C-64-Assembler und Maschinensprache-Tagen bisher fest davon ausgegangen, daß ein Texteditor keine Randnotizen geheim hält, sondern ALLE Zeichen anzeigt.

Nein, das ist nicht üblich.
Steuerzeichen, die im Editor eine definierte Funktion haben (Zeilenumbruch, Tabulator), werden interpretiert und normalerweise nicht nochmal sichtbar dargestellt; andere Steuerzeichen werden je nach Editor als Symbole, als Esc-Sequenzen, als Hexcodes oder auch gar nicht angezeigt.

So wie die Datei aufgebaut ist, egal was für Zeichen: Sonderzeichen, Steuerzeichen; jedes Byte wird angezeigt.

Das ist nur bei einem Hex-Editor so. Der zeigt dir wirklich Byte für Byte an, ohne den Dateiinhalt jedoch zu interpretieren.

Die 2 Bytes (BOM?), die die DOS-Version mehr hat, zeigt mir mein Editor nicht an.

Erstens: Die BOM hat 3 Byte, und die spielt hier keine Rolle; die gibt's auch nur bei UTF-Codierungen. Der Unterschied entsteht hier wirklich nur durch die unterschiedliche Repräsentation des Zeilenumbruchs.

Ciao,
 Martin

[Johnny B.]

Hi Martin,

Der Unterschied entsteht hier wirklich nur durch die unterschiedliche Repräsentation des Zeilenumbruchs.

--- Danke für die Erklärung!

Ich wußte es gibt bestimmt keine Wirkung ohne Ursache!

Bisher habe ich geglaubt, reine Textdateien würden wie Bilder, systemübergreifend gleich sein, also DOS, MAC oder WHATEVER. Dann sind die Textdateien nun doch nicht so rein...

DANKE!
Johnny

[Struppi]

In der HEX-Darstellung sind beide Dateien 100% gleich.

<lange pause, furchen am kopf vom kratzen>

AAAaaaaaaahhh, Moment: jetzt ich sehe einen Unterschied: unten im Editor steht einmal "MAC" und einmal "DOS". Verflucht...

Diese Fehlerbeschreibung kann so nicht stimmen. Da du in dem Fall im Hex Editor einen Unterschied sehen musst, da die Zeilenumbrüche unterschiedlich sind.

Also falls irgendwer irgendwann mal unerwartete 500er Fehler im laufenden Betrieb feststellt - alles hat eine Ursache, auch wenn manche schwierig zu entdecken sind.

Sehr sinnvoll ist, und ich verstehe auch nicht warum manche Perl nur auf dem Server testen, ist eine lokale Installation, wo du die Ausgabe des Perlskriptes direkt in der Konsole prüfen kannst. In dem Falle hättest du den Fehler sofort gesehen.

Struppi.

[Johnny B.]

Sehr sinnvoll ist, und ich verstehe auch nicht warum manche Perl nur auf dem Server testen, ist eine lokale Installation, wo du die Ausgabe des Perlskriptes direkt in der Konsole prüfen kannst. In dem Falle hättest du den Fehler sofort gesehen.

--- ich habe Perl auch lokal installiert. Aber beim lokalen Installieren der mySQL-Datenbank bin ich irgendwo stecken geblieben. Das habe ich bisher nicht zum Laufen gebracht. Somit, und weil ich ziemlich pragmatisch an das Programmieren herangehe, bleibt mir erstmal nur das Testen auf dem Server. Learning by losing... ;)

[Struppi]

--- ich habe Perl auch lokal installiert. Aber beim lokalen Installieren der mySQL-Datenbank bin ich irgendwo stecken geblieben. Das habe ich bisher nicht zum Laufen gebracht. Somit, und weil ich ziemlich pragmatisch an das Programmieren herangehe, bleibt mir erstmal nur das Testen auf dem Server. Learning by losing... ;)

#!/usr/bin/perl -w  
print "Content-type: text/html\n\n";  
print "Hallo!";

Wo ist denn in diesem Code eine Datenbank nötig?

Struppi.

[Johnny B.]

#!/usr/bin/perl -w

print "Content-type: text/html\n\n";
print "Hallo!";

>   
> Wo ist denn in diesem Code eine Datenbank nötig?  

\--- woher sonst soll denn das PRINT bitte wissen, wem es "Hallo" sagen soll? ?? ;)

[Struppi]

Wo ist denn in diesem Code eine Datenbank nötig?
--- woher sonst soll denn das PRINT bitte wissen, wem es "Hallo" sagen soll? ?? ;)

Dir ist schon klar, dass ich dir lediglich einen Weg aufzeigen wollte, wie du solche Fehler, um die es hier in dem Thread ging, deutlich schneller entdecken könntest?

Struppi.

[Johnny B.]

Dir ist schon klar, dass ich dir lediglich einen Weg aufzeigen wollte, wie du solche Fehler, um die es hier in dem Thread ging, deutlich schneller entdecken könntest?

--- just kidding... :-)

Bevor ich gelernt habe, mySQL-Datenbanken zu benutzen, habe ich für die Datenspeicherung Text-Dateien benutzt. Das lief hüben wie drüben genauso. Die mySQL-Datenbank auf meinem Heimrechner genauso aufzusetzen wie sie auf dem Server ansprechbar ist, mißlang mir bis dato. Und so habe ich dann eben auf dem Server getestet, etwas mürrisch zwar, weil deutlich langsamer und eben weil ich hier im Forum gelesen habe, es sei schlauer, Perl selbst zu installieren und offline zu testen; und weil das auch noch stimmte - naja, so kam das.

Ursprung meines Threads war ja, daß das Script, an dem ich gearbeitet habe, nicht mehr funktioniert hat. Dort verwende ich mySQL. Aber ich werde dies zum Anlaß nehmen, mir nochmal die WinSQL-Installation und die dazugehörigen Einstellungen vorzunehmen. Vielleicht kriege ich es ja jetzt zum Laufen, es ist bestimmt schon ein Jahr her, daß ich daran gescheitert bin. Denn eleganter und schlauer, schneller und schöner und dazu noch weniger fehleranfällig ist es schon, wenn man offline testen kann. ...

Johnny

[Struppi]

Aber ich werde dies zum Anlaß nehmen, mir nochmal die WinSQL-Installation und die dazugehörigen Einstellungen vorzunehmen. Vielleicht kriege ich es ja jetzt zum Laufen, es ist bestimmt schon ein Jahr her, daß ich daran gescheitert bin.

Ich hab gerade gestern eine aktuelle Verison installiert (nach zig Jahren, da war irgendeine 4'er mySQL Version drauf). Und es hat im grossen und ganzen geklappt (nur die alten Daten waren weg und man sollte vorher die alte Version deinstallieren)

Struppi.