PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Perl-Skript nicht aufrufbar (Xampp1.6.2)



Seiten : [1] 2

van_houten
15.06.07, 20:56
Ahoi ans Forum,
zuallererst eine Warnung: Hier fragt ein blutiger Anfänger in Sachen Linux bzw. Apache-Server! Ich werde ich mich allerdings bemühen, eine präzise und nachvollziehbare Frage zu stellen.

Ich mache meine ersten Gehversuche in der Web-Programmierung und möchte zu diesem Zweck meine PHP- und Perl-Skripte mittels eines lokal installierten Xampp-Servers testen. Das klappt für PHP wunderbar, nur Perl-Dateien lassen sich nicht vom Browser aus aufrufen. Die dabei ausgegebene Fehlermeldung im Browser ist mir nicht verständlich - Fehlkonfiguration?


<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
you@example.com and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.2.4 (Unix) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e PHP/5.2.2 mod_apreq2-20051231/2.5.7 mod_perl/2.0.2 Perl/v5.8.7 Server at localhost Port 80</address>
</body></html>

Zum Kontext:

Xampp 1.6.2 standartmäßig installiert (alle Pfadangaben beibehalten)
Nix weiter konfiguriert - Xampp startet inkl. Perl korrekt
Perl-Interpreter unter /usr/bin (im Skript korrekt vermerkt)
Perl-Dateien unter /opt/lampp/cgi-bin
sonstiges System: Suse10.2, Firefox


Wie gesagt, es geht mir ums Testen von Webseiten mit Skripten. Wie der Apache-Server im einzelnen aufgebaut und konfiguriert ist, ist für mich erst mal nachrangig. Wenn Ihr also dazu etwas schreibt, bitte die Konfig-Files genau benennen und Angaben Newbie-gerecht aufbereiten. Falls Ihr noch Infos aus Konfig- oder Log-Dateien zur Fehleranalyse braucht- sagt's mir, ich poste die dann.

Also vielen Dank im Voraus, van_houten

suck
15.06.07, 21:00
Kannst Du ein Rechteproblem ausschliessen?

Angenommen der Apache läuft unterm dem User "xyz". Kannst Du als User "xyz" das Perl-Script in Verzeichnis /bla/blub/ ausführen?

Wie genau wird das Perlscript über PHP aufgerufen/ausgeführt? Bitte Codefragmente posten.

van_houten
15.06.07, 21:13
Ach ja, die Rechte-Frage. Hätte ich gleich im ersten Posting ansprechen sollen, ich Dödel.
Also Rechte-Trouble kann ich in sofern ausschließen, als das das Problem auch unter einer root-Anmeldung vorhanden ist. Außerdem habe ich mir im User-Account zu Testzwecken volle Rechte für den Ordner opt/lampp und alle Unterordner verschafft. Also das wirds nicht sein.

Die zweite Frage versteh ich nicht ganz. Ich möchte das fragliche Perl-Skript nur im Browser aufrufen, also grundsätzlich ersteinmal über die Eingabe

http://localhost/cgi-bin/fraglichesSkrip.pl
im Adressfeld des Browsers.

suck
15.06.07, 21:59
Steht in der ersten Zeile des Scripts "!#/path/to/perl"?

Auch wenn Du Dich als root anmeldest, heisst das nicht, dass der Apache unter root läuft. Schau mal mit "ps aux" unter welchem User der Apache läuft und versuch dann tatsächlich mal in einer Shell und mit diesem Useraccount "/path/to/whatever.pl" auszuführen (und zwar ohne "perl" davorzuschreiben). Bei sowas vergisst man oft irgendwas. Das passiert auch noch viel zu oft. Ich spreche aus Erfahrung ;)

Das Du Perl-Scripte direkt aufrufen kannst, habe ich nicht beachtet. Kann sowas Xampp denn ohne weiteres (ich kenne das Ding nicht wirklich)? Nun ja, der Kram mit dem PHP war dann wohl ein Fehler meinerseits.


PS: Achte darauf, dass neben Xampp nicht noch ein anderer Apache läuft, den die Distri ggf. mitgebracht hat.

BedriddenTech
16.06.07, 02:56
XAMPP liefert letzten Endes doch auch nur einen Apache-Server mit, oder? Wenn ja, führt dieser Apache eine Datei namens "error_log", in der sich auch CGI/Perl-Fehler vermerken. Guck doch mal in deinem Installationsverzeichnis nach einer Datei namens "error_log" und verfolge die mittels "tail -f", während du dein Skript aufrufst. Die Fehlermeldungen dort sind meistens weitaus informativer. :)

van_houten
16.06.07, 04:53
Also der Datei "error_log" des Apache-Servers ist folgendes zu entnehmen:

[Sat Jun 16 04:36:10 2007] [error] [client 127.0.0.1] (2)No such file or directory: exec of '/opt/lampp/cgi-bin/meinSkript.pl' failed
[Sat Jun 16 04:36:10 2007] [error] [client 127.0.0.1] Premature end of script headers: meinSkript.pl
Die Datei und der Ordner existieren aber zweifelsohne.

Auf die Eingabe in der Shell:

/opt/lampp/cgi-bin/meinSkript.pl
bekomme ich:

bash: /opt/lampp/cgi-bin/meinSkript.pl: /usr/bin/perl^M: bad interpreter: Datei oder Verzeichnis nicht gefunden
Mit "perl" davor wird das Skript korrekt interpretiert.

Helft Ihr mir weiter? Bei mir will der Groschen einfach nicht fallen.

tschloss
16.06.07, 09:02
Also der Datei "error_log" des Apache-Servers ist folgendes zu entnehmen:

[Sat Jun 16 04:36:10 2007] [error] [client 127.0.0.1] (2)No such file or directory: exec of '/opt/lampp/cgi-bin/meinSkript.pl' failed
[Sat Jun 16 04:36:10 2007] [error] [client 127.0.0.1] Premature end of script headers: meinSkript.pl
Die Datei und der Ordner existieren aber zweifelsohne.

Auf die Eingabe in der Shell:

/opt/lampp/cgi-bin/meinSkript.pl
bekomme ich:

bash: /opt/lampp/cgi-bin/meinSkript.pl: /usr/bin/perl^M: bad interpreter: Datei oder Verzeichnis nicht gefunden
Mit "perl" davor wird das Skript korrekt interpretiert.

Helft Ihr mir weiter? Bei mir will der Groschen einfach nicht fallen.

Bei Xampp liegt das Perl-Binary woanders. ZB "/opt/lampp/bin/perl".

van_houten
16.06.07, 12:20
Das Testskript ist nun eins, wie es einfacher nicht geht, damit sich nicht doch irgendwo ein Fehler einschleicht. (siehe unten)


Bei Xampp liegt das Perl-Binary woanders. ZB "/opt/lampp/bin/perl".
Heist das, die erste Zeile des Skriptes sollte wie folgt aussehen?!

#!/opt/lampp/bin/perl
use CGI qw(:standard);
print header();
print "Hallo WorldWideWeb!";
Macht in Punkto Fehlermeldung keine Unterschied bei mir, also alles beim alten. :( Also wenn ich mich zum dumm anstelle, sei hiermit nochmals um Entschuldigung gebeten, aber ich seh`s nicht. :confused:

tschloss
16.06.07, 14:33
Das Testskript ist nun eins, wie es einfacher nicht geht, damit sich nicht doch irgendwo ein Fehler einschleicht. (siehe unten)


Heist das, die erste Zeile des Skriptes sollte wie folgt aussehen?!

#!/opt/lampp/bin/perl
use CGI qw(:standard);
print header();
print "Hallo WorldWideWeb!";
Macht in Punkto Fehlermeldung keine Unterschied bei mir, also alles beim alten. :( Also wenn ich mich zum dumm anstelle, sei hiermit nochmals um Entschuldigung gebeten, aber ich seh`s nicht. :confused:

Naja, diese Fehlermeldung

bash: /opt/lampp/cgi-bin/meinSkript.pl: /usr/bin/perl^M: bad interpreter: Datei oder Verzeichnis nicht gefunden
sollte dann nicht mehr kommen.

Hast Du mal geschaut, ob per unter /opt/lampp/bin/perl liegt, zB per
/opt/lampp/bin/perl --version?
Wenn das klappt, mach mal

/opt/lampp/bin/perl /opt/lampp/cgi-bin/meinSkript.pl

Und nimm mal ein Skript ohne CGI (woher soll der Header denn kommen)?

#!/opt/lampp/bin/perl -w
use strict;
print "Hallo WorldWideWeb!";

BedriddenTech
16.06.07, 15:13
Ich fürchte, zwei Dinge werden übersehen: Erstens macht mich die Zeile
bash: /opt/lampp/cgi-bin/meinSkript.pl: /usr/bin/perl^M: bad interpreter: Datei oder Verzeichnis nicht gefunden äußerst stutzig, das sieht aus wie eine fehlerhafte Codepage-Konvertierung o.ä. "perl^M" ist jedenfalls in 99,99% aller Fälle auf keinem System installiert. ;)
Zweitens muß jedes CGI/Perl-Skript den Content-Type mitliefern, d.h. irgendwo im Skript muß der Befehl
print "Content-Type: text/html\r\n\r\n"; vor jeder anderen Ausgabe stehen. Ein korrektes Testskript sähe also so aus:

#!/usr/bin/perl
print "Content-Type: text/html\r\n\r\n";
print "Hello, World!";
Mit "use strict; use warnings;" usw usf. kannst du ja arbeiten, wenn klar ist, daß die Systemseite einwandfrei funktioniert.

van_houten
16.06.07, 15:25
@tschloss
Ersteinmal vielen Dank für Deine Hilfe! Dann:


Hab die Header-Anweisung im Skript wie empfohlen entfernt. Das führt dazu, dass die Eingabe in der Shell korrekt interpretiert wird: Ich bekomme ein schönes "Hallo WorldWideWeb!" :) (Wir sind auf der richtigen Spur.)
Der Perl-Interpreter liegt tatsächlich unter /opt/lampp/bin/

/opt/lampp/bin/perl --version
führt zu:

This is perl, v5.8.7 built for i686-linux
Unter /usr/bin in der Version 5.8.8.
Leider bleibt der Versuch das Skript im Browser auszuführen weiter erfolglos. :( Interessanterweise kommt die im ersten Posting angeführte Fehlermeldung im Browser nicht gleich beim ersten Aufruf zustande (da passiert ersteinmal gar nichts -> blankes Fenster, alles weiß), sondern erst beim dritten oder vierten mal "Seite neu laden".

BedriddenTech
16.06.07, 15:31
Hast du den Rest (mein Beitrag) mal geprüft?

van_houten
16.06.07, 15:35
@BedriddenTech
Okay, Dein Vorschlag für ein vernünftges TestSkript ist hiermit zusätzlich übernommen -> keine Änderung des unerwünschten Verhaltens. :(

Du hast recht, die einzig wirklich bemerkenswerte Zeile in den diversen Fehlermeldungen scheint mir auch, die von Dir angesprochene. Könnte das vielleicht damit zu tun haben, dass ich aus unerfindlichen Gründen zwei verschiedene Perl-Versionen auf der Kiste habe? (Hab ich ja auch grade erst bemerkt. :confused:)

BedriddenTech
16.06.07, 15:45
Solange beide Versionen Perl 5.8.x sind, gibt es keine so gravierenden Unterschiede, daß du die feststellen könntest. Gehen wir die Sache mal Schritt für Schritt durch.

Testskript funktioniert, wenn "perl /pfad/zum/skript" aufgerufen wird.
Testskript funktioniert, wenn "/pfad/zum/skript" ohne "perl" davor aufgerufen wird: Skript muß für alle ausführbar sein (chmod +x /pfad/zum/skript), und die erste Zeile muß den korrekten Pfad zum Interpreter enthalten, also z.B. "#!/usr/bin/perl".
Benutzt deine XAMPP-Installation "suexec"? Wenn ja, findest du im Installationsverzeichnis von XAMPP eine gleichnamige Datei. Wenn die ersten beiden Punkte abgehakt sind, das Skript im Webserver aber immer noch nicht richtig geht, könntest du die mal verschieben: "mv suexec suexec.bak" im Verzeichnis, in dem "suexec" liegt (also irgendwo unter /opt/lampp).

Wenns dann immer noch nicht geht, einfach wieder melden. :)

van_houten
16.06.07, 16:00
Dank auch für Dein Engagement BedriddenTech!

Die Testskripte funktionieren in der Shell! Egal ob mit oder ohne "perl" davor, egal welchen Interpreter ich anspreche.
Deiner Anweisung, die Datei "suexec" mal aus dem Installationsverzeichnis zu verbannen, bin ich gefolgt -> alles wie gehabt: der Browser spukt nach wie vor die Meldung des ersten Posting aus.

BedriddenTech
16.06.07, 16:12
Skript setzt Content-Type, ja? Was steht denn jetzt in den Logs?

van_houten
16.06.07, 16:27
Zitat von BedriddenTech
Skript setzt Content-Type, ja?
Ja, ich benutzte bei jedem Test auch das von Dir empfohlene Skript.

Die Ausgabe der "error_log" von lampp bleibt auch gleich:

[Sat Jun 16 16:18:40 2007] [error] [client 127.0.0.1] (2)No such file or directory: exec of '/opt/lampp/cgi-bin/testskript.pl' failed
[Sat Jun 16 16:18:40 2007] [error] [client 127.0.0.1] Premature end of script headers: testscript.pl
Ich hoffe ja inständig, ich mache nicht im Vorfeld irgendeinen Newbie-Fehler, der mir nicht in den Sinn will. Dagegen spricht für mich ein wenig der Umstand, dass es ja mit PHP tadelos funktioniert.

BedriddenTech
16.06.07, 16:38
Darf der Benutzer, unter dem der Apache läuft, das Verzeichnis "/opt/lampp/cgi-bin/" überhaupt betreten (Sprich: Darf er /opt, /opt/lampp und /opt/lampp/cgi-bin betreten)? Darf er, wenn er da drin ist, ./testskript.pl ausführen? Prüfe das mal mit einem "su lampp_user", und gib dann die entsprechenden Befehle ein.

van_houten
16.06.07, 17:04
Also grundsätzlich hantiere ich gerade (nur zu Testzwecken natürlich :cool:) als root herum, und der darf ja zumindest afaik jeden Pfad betreten, quasi auch austrampeln ;).
Aber in vollem Ernst: Das Testskript laüft in der Shell als root oder im User-Account, ganz egal. Aber was hat den bitteschön der User "nobody" hier zu suchen? (Ausgabe nach "ps aux")

root 5425 8.4 1.9 26216 15116 ? Ss 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
root 5445 0.0 0.1 2604 1240 pts/1 S 16:57 0:00 /bin/sh /opt/lampp/bin/mysqld_safe --datadir=/opt/lampp/var/mysql --pid-fi
nobody 5466 1.2 1.6 100328 12764 pts/1 Sl 16:57 0:00 /opt/lampp/sbin/mysqld --basedir=/opt/lampp --datadir=/opt/lampp/var/mysql
nobody 5467 0.0 1.3 23448 10736 ? S 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 5475 0.0 0.1 5720 1344 ? Ss 16:57 0:00 proftpd: (accepting connections)
nobody 5491 0.0 1.5 26216 12356 ? S 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 5492 0.0 1.5 26216 12336 ? S 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 5493 0.0 1.5 26216 12336 ? S 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 5494 0.0 1.5 26216 12336 ? S 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
nobody 5499 0.0 1.5 26216 12336 ? S 16:57 0:00 /opt/lampp/bin/httpd -k start -DSSL -DPHP5
1000 5502 0.0 0.1 2480 856 pts/1 R+ 16:57 0:00 ps aux
Ich verstehs nicht. Bitte nicht prügeln!

BedriddenTech
16.06.07, 17:52
Der Apache hat eine Konfigurationsdatei, in der steht, zu welcher User-ID er wechseln soll, nachdem beim er alles erledigt hat, was er nur als root tun kann (z.B. Port 80 öffnen o.ä.), das ist vollkommen korrekt so.
Guck dir doch mal deine httpd.conf an, da müßte es einen Bereich für dein /cgi-bin/ geben. Schau mal, ob du da überhaupt Skripte ausführen darfst - evtl. erlaubt der Apache nur Skripte, die auf .cgi enden, und verbietet .pl, o.ä.

van_houten
16.06.07, 18:16
In der "httpd.conf" ist an entsprechender Stelle folgendes zu lesen:

<Directory "/opt/lampp/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
Ein Skript mit der Endung ".cgi" versehen, führt ebenfals nicht zum Erfolg.

BedriddenTech
16.06.07, 18:23
Ersetz das "none" bei den "Options" doch mal durch ein "+ExecCGI" (mit dem +!), starte den Apachen neu und schau mal, was passiert. (Obwohl ich zweifle, daß es das sein könnte.)

BedriddenTech
16.06.07, 18:47
Oh, eines noch: Es wird auch tatsächlich NUR der Apache aus deiner LAMPP-Installation gestartet, und keine Distributions-Installation, ja? Bitte nochmal nachprüfen!

van_houten
16.06.07, 19:15
Ich bin ja beeindruckt von so viel Ideenreichtum, aber leider, leider - ("+ExecCGI") das wars auch net.
Ich bin mir auch ganz sicher, dass nur ein Apache läuft.

Übrigens bekomme ich, seitdem ich mir User-Account volle Zugriffsrechte auf den Installationspfad eingeräumt habe, folgende Fehlermeldung beim Starten von xampp:

Warning: World-writable config file '/opt/lampp/etc/my.cnf' is ignored
Das dürfte aber, wenn ich mir "my,cnf" so anschaue, eigentlich nur MySQL betreffen, richtig?

BedriddenTech
16.06.07, 22:32
Richtig, das bezieht sich auf MySQL. Aus Sicherheitsgründen wird die Konfigurationsdatei, die für alle beschreibbar ist, ignoriert.
Puh, so langsam wirds wirklich kniffelig. Wenn du "cat /dein/skript" ausführst, siehst du dann diese ^M noch am Zeilenende?

tschloss
17.06.07, 09:22
PART DELETED.

War denn das Rechtethema geklärt? Schon mal per chmod 777 /opt/lampp/cgi-bin/testskript.pl alles aufgemacht?

Und noch was:
Bei XAMPP liegen 2 Testskripte in cgi-bin. Hast du die mal probiert: "http://localhost/cgi-bin/printenv" oder "..test-cgi"? Sind zwar Shell-Skripte, aber wäre ja schon mal ein Schritt.

Übrigens ist bei meinem XAMPP anscheinen auch mod_perl installiert zu sein. Dann könntest du den cgi-Kram vielleicht auch sparen? Schon mal versucht, es wie bei php zu machen?

van_houten
17.06.07, 13:42
Servus, Ihr netten Linuxer - langsam fühl ich mich hier ein wenig daheim! :)
Zum Text:
Die Rechteproblematik ist unbedingt durch. Zur Sicherheit hab ich, Deinem Rat folgend tschloss, "chmod 777" nochmal über alle Skripte gejagt - sie waren aber auch zuvor definitv lesbar/schreibbar/ausführbar.

Die beiden Testskripte "printenv" und "test-cgi" funktionieren anstandslos, in der Shell, als auch unter lampp. Was läuft da anders? :confused: Und die Konfusion wird noch größer, wenn Ihr Euch diese Ausgaben in der Shell einmal anschaut:


van_houten@second-linux:~> cat /opt/lampp/cgi-bin/meinskript.pl
#!/usr/bin/perl
print "Content-Type: text/html\r\n\r\n";
print "Hello,World!";
van_houten@second-linux:~> /opt/lampp/cgi-bin/meinskript.pl
bash: /opt/lampp/cgi-bin/meinskript.pl: /usr/bin/perl^M: bad interpreter: Datei oder Verzeichnis nicht gefunden
aber:

van_houten@second-linux:~> cat /opt/lampp/cgi-bin/meinskript.pl
#!/usr/bin/perl -w
print "Content-Type: text/html\r\n\r\n";
print "Hello, World!";
van_houten@second-linux:~> /opt/lampp/cgi-bin/meinskript.pl
Content-Type: text/html

Hello, World!
Wie man an der Dateiausgabe "cat" sieht, ist der Unterschied in den Skripten lediglich die Option "-w" in der Interpreter-Adresse. Dieses Verhalten ist reproduzierbar auch für andere perl-Optionen, z.B. "-X". Was soll denn das? Die genannten Optionen sind doch insofern vernachlässigbar, als das sie nur die Ausgabe von Fehlermeldungen beeinflussen. (Ich denke damit ist auch Deine Frage, BedriddenTech, erst einmal beantwortet.)


Übrigens ist bei meinem XAMPP anscheinen auch mod_perl installiert zu sein. Dann könntest du den cgi-Kram vielleicht auch sparen? Schon mal versucht, es wie bei php zu machen?Damit kann ich leider nichts so richtig anfangen. :o Nur ein kleiner Wink, tschloss, und ich tu's. ;)

Grüße

tschloss
17.06.07, 14:04
Hmmm. Verwendest Du vlt. einen Editor, der im Windows-Format abspeichert (CR+LF)?
Schau mal mit "xdd meinskript.pl" hinein.
Mach mal spaßhalber ein Leerzeichen hinter "#!/usr/bin/perl".

Was macht eigentlich das "-w"-Skript, wenn du es aus dem Browser rufst?

mod_perl: http://perl.apache.org/
Was passiert, wenn du ein Perl-Skript einfach in /opt/lammp/htdocs legst und es mit http://localhost/meinskript.pl aufrufst, eben so, wie du es mit PHP-Skripten auch machst. Ich weiss nicht, inwieiwet sich beide Schnittstellen ins Gehege kommen. (Die Tatsache, dass Du zwei Perl-Versionen auf der Kiste hast, ist sicher auch nicht hilfreich - sehe aber im Moment den direkten Zusammenhang noch nicht).

van_houten
17.06.07, 14:42
Was passiert, wenn du ein Perl-Skript einfach in /opt/lammp/htdocs legst und es mit http://localhost/meinskript.pl aufrufst, eben so, wie du es mit PHP-Skripten auch machst.:D Das funktionert. So was - hätte ich da nicht selbst drauf kommen können/müssen?! Uff, was ne schwere Geburt. Tausend Dank! (Mein Handbuch zur Web-Programmierung sagte mir, dass Perl-Skripte unbedingt in den Ordner "/opt/lampp/cgi-bin" gehören. Vertrauen ist gut - Kontrolle ...) Somit kann ich ersteinmal meiner Absicht folgend meinen PHP- und Perl-Code testen. (siehe erstes Posting) Das ganze beschriebene seltsame Verhalten geht dann vielleicht doch aufs Konto der zwei verschiedenen Perl-Varianten auf meinem Rechner. Ich werd dann die, welche nicht von Xampp geliefert wurde, runterschmeißen und dann Bericht erstatten.

Was macht eigentlich das "-w"-Skript, wenn du es aus dem Browser rufst?
Den Bekannten Fehler produzieren. (siehe erstes Posting)

Hmmm. Verwendest Du vlt. einen Editor, der im Windows-Format abspeichert (CR+LF)?

Na ich hoff doch nicht! Ich verwende bei den ganzen Tests Suse-Bordmittel (Kate) mit den Einstellungen "KDE Standart" und "Unix".

Bis dahin Danke an alle, die geholfen haben. Was ich besonders angenehm fand: Tatsächlich alle Antworten waren sehr konstruktiv - kein genervter 'Newbie-Verschrecker' dabei.
Und vielleicht findet sich bei mir noch ne Lösung, die alle Unklarheiten beseitigt - mal sehen.

Grüße

Edit:

Mach mal spaßhalber ein Leerzeichen hinter "#!/usr/bin/perl".
Hatte ich. Bringt nichts.

tschloss
17.06.07, 14:52
Den Bekannten Fehler produzieren. (siehe erstes Posting)

Die "#!/usr/bin/perl -w" Variante hatten wir aber doch erst etwas später eingeführt. Naja, mag ja auch wurscht sein. Jedenfalls würde ich sagen, das "...perl^M bad interpreter"-Problem kommt aus dem Dateiformat. Kommt da noch iregndwas hinter "perl", dann erkennt das System "perl" als Interpreter und nicht "perl^M". EDIT: ah, sehe, du hattest es mit Leerzeichen probiert. Anyway...



Bis dahin Danke an alle, die geholfen haben. Was ich besonders angenehm fand: Tatsächlich alle Antworten waren sehr konstruktiv - kein genervter 'Newbie-Verschrecker' dabei.
Grüße
Das passiert immer nur dann, wenn der "Problemhaber" selbst nicht mitarbeitet, d.h. Vorschläge nicht umsetzt, interprtierte Fehlermeldungen zurückgibt etc. Hier lief das ja fein.

Viel Spaß weiterhin.