nicht angemeldet
Problem mit Apache :-)
0 0 0 0 Kein Problem mehr mit Apache :-)
Problem mit Apache :-)
Nachdem ich endlich den Apache-Server zum Laufen gebracht habe (mit SSI! Hurra!), habe ich noch ein Problem:
Ich möchte einen Textcounter per SSI einbinden. Allerdings finde ich nach Aufruf der Seite und des <!--exec cgi="/cgi-bin/counter.pl"--> einen Eintrag mehr in der error.log:
[Mon Jul 19 17:55:38 1999] [error] [client 127.0.0.1] couldn't spawn child process: c:/eigene dateien/internet/cncstation.neu/cgi-bin/counter.pl
Da CGIs allgemein mit dem Apache bei mir nicht ausgeführt werden, dachte ich an ein Konfigurations-Problem mit dem Apache. Ich beschäftige mich seit Samstag damit, kam aber noch nicht dahinter. Die Initialisierung für ausführbare Dateien sieht folgendermaßen aus:
[...]
ScriptAlias /cgi-bin/ "C:/Eigene Dateien/Internet/cncstation.neu/cgi-bin/"
<Directory "C:/Eigene Dateien/Internet/cncstation.neu">
Options ExecCGI Includes
Order allow,deny
Allow from all
</Directory>
<Directory "C:/Eigene Dateien/Internet/cncstation.neu/cgi-bin">
Options ExecCGI
AllowOverride None
</Directory>
[...]
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
AddHandler cgi-script .pm
AddHandler cgi-script .exe
AddType text/html .shtml
AddHandler server-parsed .shtml
[...]
das Counter-Script habe ich auch da:
#!/usr/bin/perl
Counter für CnCStation.de
open (COUNTER, "<counter.dat");
$count = <COUNTER>;
close (COUNTER);
print $count;
$count++;
open (COUNTER, ">counter.dat");
print COUNTER $count;
close (COUNTER);
Die Syntax im Script ist laut perl -w korrekt.
Ich bin für jede Hilfe sehr dankbar.
MfG Florian Auer
-
Liest du dir eigentlich durch, was die Leutchen hier
so schreiben ? (dann würde manches vielleicht schneller gehen)Den Hinweis hast du schon 2 mal bekommen !
In welchem Verzeichnis steht dein Perlinterpreter ?
Wie lautet die Pfadangabe in deinem Script ?Gruß Udo
-
Liest du dir eigentlich durch, was die Leutchen hier
so schreiben ? (dann würde manches vielleicht schneller gehen)Natürlich, nur leider half mir alles herzlich wenig, weil es nicht funktionierte. Oder soll ich ständig ein Posting dahintergeben wo drinsteht "Geht nicht, deine Hilfe hat mir nichts gebracht"? Ich wurde von Antje schon angemailt, weil ich das Forum zugemüllt habe!
Den Hinweis hast du schon 2 mal bekommen !
Leider hat er nie funktioniert
In welchem Verzeichnis steht dein Perlinterpreter ?
das steht in der PATH-Variable, und darum brauch' ich mich nicht kümmern, weil ich durch eine Logfile weiß, dass der perl-Interpreter ausgeführt wird
Wie lautet die Pfadangabe in deinem Script ?
welche Pfadangabe?
wenn ich bei dem exec cgi den kompletten Pfadnamen hinschreibe, dann bringt er mir folgende Meldung:
[Mon Jul 19 23:59:16 1999] [error] [client 127.0.0.1] invalid CGI ref "C:/Eigene Dateien/Internet/cncstation.neu/cgi-bin/counter.pl" in c:/eigene dateien/internet/cncstation.neu/home/newspage.shtml
MfG Florian Auer
-
-
Nachdem ich endlich den Apache-Server zum Laufen gebracht habe (mit SSI! Hurra!), habe ich noch ein Problem:
Ich denke das Forum ist fuer Probleme da, die der eine oder andere hat - oder auch einen Rat den man braucht. Meiner Meinung nach ersetz er aber nicht das Lesen von Anleitungen, Manuals, FAQs und was es sonst noch so gibt. Gerade zu Apache findest Du das im Internet zu hauf. Und wenn Du dann soweit durchblickst, dass Du eine konkrete Frage zu einem Problem stellen kannst, wird Dir sicher auch besser geholfen werden koennen.
Viele Gruesse, Thomas Hieck
-
Vielen Dank für deine nette Hilfe. Nur meinst du wirklich, ich würde hier was posten, wenn ich's nicht selber auch rausbekommen würde (schon der Ehre halber ;-) )? Ich habe mich stundenlang durch die englische Apache-Dokumentation gequält. Jetzt funktionieren die SSIs. Aber keine CGIs.
Auf mancher hiesiger Leute Hilfe kann ich gut und gerne verzichten. Aber ich hab' auch noch was anderes zu tun, als mich stunden- bzw. tagelang wegen einem Problem rumzuquälen, das mir mit Sicherheit einer im SelfHTML-Forum auch erklären kann. Aber scheinbar mangelt es an einiger Leute Kompetenz zu diesen Themen.
Es gibt hier Leute, die ihr Wissen gerne weitervermitteln, weil sie sich freuen, dass sie jemandem helfen können. Aber es gibt hier leider auch solche, die zu Themen, die schon öfter von einer Person angesprochen wurden, nur dumme Bemerkungen ablassen, statt ihre Hilfe vielleicht etwas detaillierter ausdrücken. Es soll Leute geben, die eben manche Sachen nicht so schnell kapieren, wie andere. Ich z.B. hasse Konfigurations-Dateien, wo mehr Kommentar als Konfiguration drinsteht (Apache!). Und wenn ich da mal was zweimal nicht checke, kommt beim dritten Mal ein blöde Antwort. Aber scheinbar ist das hier so üblich bei manchen Leuten. Für mich sollten nur noch die Leute hier rein dürfen, die wirklich Zeit und Lust haben sich mit Problemen anderer zu beschäftigen. Ich möchte mich vom Gegenteil dieser nicht ausschließen. Imho sind hier rund 30% aller, wirklich die, die sowas können. Aber die restlichen 70% wissen's auch, nur wird's denen ab dem 2ten Mal zu dumm einem zu helfen. Mein Gott, einer hat eben mehr Probleme als die andern, und traut sich diese zu offenbaren. Deshalb verstehe ich nicht, weshalb , wenn eine Frage zwei- oder dreimal gestellt wird, und die Antwort immer noch nicht ganz begriffen wurde, nur noch so saudumme (tschuldigung) Antworten bekommen werden, dass einem da manchmal das Weinen kommen könnte.
Das ist mal meine Ansicht von den ganzen Leuten, die meinen, bloß weils bei ihnen funktioniert, sind sie was besseres.MfG Florian Auer
P.S: Auch wenn ich nicht ganz so beliebt bin in diesem Forum: ich will es nicht missen.
-
»» Nur meinst du wirklich, ich würde hier was posten, wenn ich's nicht selber auch rausbekommen würde (schon der Ehre halber ;-) )? Ich habe mich stundenlang durch die englische Apache-Dokumentation gequält. Jetzt funktionieren die SSIs. Aber keine CGIs.
Tut mir leid - nach eigenen Angaben machst DU das seit letzten Samstag. Meinst du es gibt riesige Anleitungen, FAQ, und jede Menge Newsgroups zu Apache, wenn jeder alles innerhalb von 2 Tagen beherrschen wuerde. Dann koennten Firmen in Zukunft auch Schueler als Aushilfe anstellen um mal eben schnell nach der Schule den Server zu betreuen.
Ich bezweifele also, dass Du Dich ernsthaft gekuemmert hast. Das geht aber leider immer eine praezisen Anfrage vorraus, wenn die Moeglichkeit zur Hilfe gegeben sein soll und hat nichts mit Willen oder Unwillen zu tun Dir zu helfen.
Deshalb verstehe ich nicht, weshalb , wenn eine Frage zwei- oder dreimal gestellt wird, und die Antwort immer noch nicht ganz begriffen wurde, nur noch so saudumme (tschuldigung) Antworten bekommen werden, dass einem da manchmal das Weinen kommen könnte.
Nochmal langsam: Die meisten helfen gern, sonst waeren sie nicht hier, aber der Fragende muss seine Frage auch entsprechend recherieren, um sie so stellen zu koennen, dass sie eine beantwortbare Frage daraus wird. Das erfordert auch eigene Beschaeftigung mit dem Problem.
Ich denk hier gibt es genug Fachleute auch fuer Apache und es ist bezeichnend, dass nicht die Antwort innerhalb von einer Stunde, wie sonst ueblich da ist. Das nur zur Anregung.
Viele Gruesse, Thomas Hieck
-
-
-
hi!
[Mon Jul 19 17:55:38 1999] [error] [client 127.0.0.1] couldn't spawn child process: c:/eigene
dateien/internet/cncstation.neu/cgi-bin/counter.plDas bedeutet einfach, dass das Perl-Skript nicht ausgeführt werden konnte, normalerweise weil die Shebang-Angabe nicht stimmt.
bye, Frank!
-
Hallo Frank,
Das bedeutet einfach, dass das Perl-Skript nicht ausgeführt werden konnte, normalerweise weil die Shebang-Angabe nicht stimmt.
was ist eine Shebang-Angabe? Das Zeugs mit dem <!--#exec cgi="..."-->?
MfG Florian Auer
-
hi!
was ist eine Shebang-Angabe?
#!/usr/bin/perl
bye, Frank!
-
was ist eine Shebang-Angabe?
#!/usr/bin/perlGuter Witz! Die wird nämlich unter DOS nicht ausgewertet.
Zu Perl-CGI unter Apache unter DOS ist auch irgendwie keine wirklich gute Info zu finden,
da das ding nunmal für Unix gebaut ist. (Die
sollen WinDOS endlich mal Posix konform
machen!!!)Ich helfe mir dabei so, daß ich eine
RewriteRule definiere, die mir jeden
Scriptaufruf der Form /cgi-bin/*.pl
in /cgi-bin/*.bat umschreibt.
Dann habich für jedes Script eine Batchdatei,
in der nur die zeile @perl scriptname.pl
drinsteht. Das funktioniert irgendwie ganz gut.Falls es dafür eine bessere Lösung gibt,
würde mich die auch brennend interessieren.Andere Server haben dieses Problem unter
DOS irgendwie nicht, weil sie oft die Registry
bezüglich der Dateitypen auswerten, oder
weil einstellbar ist, daß Dateien mit der Endung
.pl von c:\bin\perl mit den parametern -xyz
auszuführen sind.HTH
GONZO-
was ist eine Shebang-Angabe?
*Den* Namen kannte ich bisher auch nicht - woher kommt der, Gonzo?
#!/usr/bin/perl
Guter Witz! Die wird nämlich unter DOS nicht ausgewertet.Florian, wenn Du die mehrfach angegebenen korrekten Lösungstips ignorierst, dann wirst Du Dich selbst unnnötig quälen ... und die Leser gleich mit.
Ob diese Anweisung ausgewertet wird, das hängt nicht vom Betriebssystem ab, sondern vom Webserver.
Apache wertet diese Angabe aus - egal ob unter UNIX oder unter Win32.Zu Perl-CGI unter Apache unter DOS ist auch irgendwie keine wirklich gute Info zu finden,
Reden wir von DOS oder von Win32? Bitte zukünftig präzise Angaben ...
Falls es dafür eine bessere Lösung gibt,
würde mich die auch brennend interessieren.Selbstverständlich.
Da Du bereits den Perl-Interpreter über den PATH adressieren kannst, würde ich "#!perl" in die 1. Zeile des Skripts schreiben. Bei mir daheim (Windows95) funktioniert das mit Apache 1.3.2.Andere Server haben dieses Problem unter
DOS irgendwie nicht, weil sie oft die Registry
bezüglich der Dateitypen auswerten, oder
weil einstellbar ist, daß Dateien mit der Endung
.pl von c:\bin\perl mit den parametern -xyz
auszuführen sind.Und genau das hasse ich.
Ich will mein Perl-Skript durch einen Doppelklick in den Editor laden können, um schnell etwas darin ändern zu können. Das kann ich aber nicht, wenn der Webserver mich dazu zwingt, *.pl mit dem Perl-Interpreter zu verbinden.Apache ist "friedlich" und ändert nichts am Betriebssystem herum, bloß um seine CGI-Skripts ausführen zu können.
-
Florian, wenn Du die mehrfach angegebenen korrekten Lösungstips ignorierst, dann wirst Du Dich selbst unnnötig quälen ... und die Leser gleich mit.
Ich ignoriere sie doch gar nicht. Ich schaue alle 30 min hier rein, nur um eine Lösung für das Problem zu bekommen. Nur leider verstehe ich die Lösungen einfach nicht.
Ob diese Anweisung ausgewertet wird, das hängt nicht vom Betriebssystem ab, sondern vom Webserver.
Apache wertet diese Angabe aus - egal ob unter UNIX oder unter Win32.Das weiß ich auch! mit dem Befehl start()
Zu Perl-CGI unter Apache unter DOS ist auch irgendwie keine wirklich gute Info zu finden,
Reden wir von DOS oder von Win32? Bitte zukünftig präzise Angaben ...
Win32. DOS ist albern. Mit Lynx in einem 24x80-Zeichen-Raster durch das WWW. ;-)
Falls es dafür eine bessere Lösung gibt,
würde mich die auch brennend interessieren.Selbstverständlich.
Da Du bereits den Perl-Interpreter über den PATH adressieren kannst, würde ich "#!perl" in die 1. Zeile des Skripts schreiben. Bei mir daheim (Windows95) funktioniert das mit Apache 1.3.2.Der Perl-Interpreter ist bei mir auch in 'PATH' adressiert. Und ich habe auch in allen Scripts jetzt '#!perl' stehen. Nur bekomme ich dann wieder mal einen neuen Eintrag in der error.log statt der Ausgabe auf dem Bildschirm (da kommt HTTP 500 :-( ):
[Tue Jul 20 17:56:46 1999] [error] [client 127.0.0.1] malformed header from script. Bad header=19: c:/eigene dateien/internet/cncstation.neu/cgi-bin/counter.pl
Und genau das hasse ich.
Ich will mein Perl-Skript durch einen Doppelklick in den Editor laden können, um schnell etwas darin ändern zu können. Das kann ich aber nicht, wenn der Webserver mich dazu zwingt, *.pl mit dem Perl-Interpreter zu verbinden.»»
Willkommen im Club! Denn das funzt meist sowieso nicht, weil das Konsolenfenster gleich wieder weg ist.Apache ist "friedlich" und ändert nichts am Betriebssystem herum, bloß um seine CGI-Skripts ausführen zu können.
Zum Glück! Aber die Konfiguraionsdateien-Lösung ist auch nicht gerade das beste. Apache 2.0 soll ja einen Browserbasierten Einstellungs-Dialog haben.
MfG FLorian Auer
-
Da Du bereits den Perl-Interpreter über den PATH adressieren kannst, würde ich "#!perl" in die 1. Zeile des Skripts schreiben. Bei mir daheim (Windows95) funktioniert das mit Apache 1.3.2.
Der Perl-Interpreter ist bei mir auch in 'PATH' adressiert. Und ich habe auch in allen Scripts jetzt '#!perl' stehen. Nur bekomme ich dann wieder mal einen neuen Eintrag in der error.log statt der Ausgabe auf dem Bildschirm (da kommt HTTP 500 :-( ):Aber wir sind uns einig, daß wir jetzt einen Schritt weiter sind, wo der Perl-Interpreter endlich gefunden wird?
Als nächstes werden wir wohl das Skript debuggen müssen. Also: URL des CGI-Aufrufs per Browser bestimmen, der passenden Environment-Variablen zuweisen, Perl-Skript ohne Webserver in simulierter CGI-Umgebung ausführen und sehen, was passiert. (Siehe ausführliche Beschreibung in meiner E-Mail.)[Tue Jul 20 17:56:46 1999] [error] [client 127.0.0.1] malformed header from script. Bad header=19: c:/eigene dateien/internet/cncstation.neu/cgi-bin/counter.pl
Immerhin ranzt er jetzt nicht mehr ab, weil er das Skript überhaupt nicht ausführen kann, sondern er jammert nun darüber, daß ihm das Format der erzeugten Ausgabe nicht paßt.
Womöglich ist das jetzt kein korrekter http-Header, sondern eine Fehlermeldung, weil das Perl-Skript binär auf den Server transportiert wurde oder was auch immer - deshalb: siehe oben. (Vorher "perl -c counter.pl" kann auch helfen.)
Man kann halt auch mehr als einen Fehler machen ...Ich will mein Perl-Skript durch einen Doppelklick in den Editor laden können, um schnell etwas darin ändern zu können. Das kann ich aber nicht, wenn der Webserver mich dazu zwingt, *.pl mit dem Perl-Interpreter zu verbinden.
Willkommen im Club! Denn das funzt meist sowieso nicht, weil das Konsolenfenster gleich wieder weg ist.Klar - aber WebSite zwingt mich dazu, das so zu machen! Sonst führt er kein CGI-Skript aus.
Zum Perl-Ausführen habe ich jeweils eine Batch-Datei mit zwei Kommandos drin:
perl <scriptname>
pause
*Die* klappt nicht sofort zu ...Apache ist "friedlich" und ändert nichts am Betriebssystem herum, bloß um seine CGI-Skripts ausführen zu können.
Zum Glück! Aber die Konfiguraionsdateien-Lösung ist auch nicht gerade das beste. Apache 2.0 soll ja einen Browserbasierten Einstellungs-Dialog haben.Das kann wohl schon Apache 1.3 - ich habe es aber noch nicht versucht.
Und ich werde mir auch dreimal überlegen, ob ich irgend ein Programm an meine sorgsam kommentierte Webserver-Konfiguration ranlasse - nachher sind womöglich die Kommentare weg und ich darf raten, was ich mir letztes Jahr dabei gedacht hatte!
Nein, an meine httpd.conf kommt nur emacs und sonst nichts. Dokumentation ist lebenswichtig, und die beste Dokumentation ist diejenige, die man findet, wenn man sie braucht - also direkt dort, wo ich Anweisungen hinschreiben muß.Außerdem habe ich dort als letzte Zeile
"include conf/<servername>.conf"
stehen - das heißt, ich habe nicht etwa die Originaldatei umgeschrieben, sondern meine Änderungen fein säuberlich in einer eigenen Datei, welche als letzte eingelesen wird und vorherige Definitionen (fast) sauber überdeckt. (Ich glaube, ein oder zwei Sachen muß man im Original ändern, weil die Installations-Defaults nicht funktionieren können - die findet man aber mit "apachectl test" sofort.)
Das erleichtert eine Migration auf einen neue Apache-Version ungeheuer - ich muß praktisch nur die include-Zeile wieder einfügen und fertig ist die Laube.
Ich kann sogar beliebig geschachtelte INCLUDES verwenden, also in meiner eigenen Konfigurations-Teildatei selbst wiederum Einträge nach Projekten etc. zerlegen, so daß ich auf einen Blick sehe, wer was wofür haben wollte. Das kann ich per graphischer Oberfläche nicht so schön - ebenso wie ich eine graphische Oberfläche nicht "mal schnell" mit grep nach "CGI" durchsuchen kann usw.-
Aber wir sind uns einig, daß wir jetzt einen Schritt weiter sind, wo der Perl-Interpreter endlich gefunden wird?
Als nächstes werden wir wohl das Skript debuggen müssen. Also: URL des CGI-Aufrufs per Browser bestimmen, der passenden Environment-Variablen zuweisen, Perl-Skript ohne Webserver in simulierter CGI-Umgebung ausführen und sehen, was passiert. (Siehe ausführliche Beschreibung in meiner E-Mail.)In diesem Teil komm' ich jetzt nicht mit. Wie meinst du das: URL des CGI-Aufrufs; Perl-Skript ohne Webserver in simulierter CGI-Umgebung ausführen; in deiner eMail stand nichts dergleichen. Environment-Variablen sind keine gesetzt bzw werden nicht benötigt.
[Tue Jul 20 17:56:46 1999] [error] [client 127.0.0.1] malformed header from script. Bad header=19: c:/eigene dateien/internet/cncstation.neu/cgi-bin/counter.pl
Immerhin ranzt er jetzt nicht mehr ab, weil er das Skript überhaupt nicht ausführen kann, sondern er jammert nun darüber, daß ihm das Format der erzeugten Ausgabe nicht paßt.
Womöglich ist das jetzt kein korrekter http-Header, sondern eine Fehlermeldung, weil das Perl-Skript binär auf den Server transportiert wurde oder was auch immer - deshalb: siehe oben. (Vorher "perl -c counter.pl" kann auch helfen.)»»
Wie soll ich die auf einen Server übertragen? Ist doch localhost!Man kann halt auch mehr als einen Fehler machen ...
leider!
Zum Perl-Ausführen habe ich jeweils eine Batch-Datei mit zwei Kommandos drin:
perl <scriptname>
pause
*Die* klappt nicht sofort zu ...hab' ich unter Xitami auch versucht. Ist aber nie funktioniert. Aber das ist nicht das Thema
Apache ist "friedlich" und ändert nichts am Betriebssystem herum, bloß um seine CGI-Skripts ausführen zu können.
Zum Glück! Aber die Konfiguraionsdateien-Lösung ist auch nicht gerade das beste. Apache 2.0 soll ja einen Browserbasierten Einstellungs-Dialog haben.Das kann wohl schon Apache 1.3 - ich habe es aber noch nicht versucht.
»»
WO????MfG Florian Auer
-
-
-
#!/usr/bin/perl
Guter Witz! Die wird nämlich unter DOS nicht ausgewertet.Ob diese Anweisung ausgewertet wird, das hängt nicht vom Betriebssystem ab, sondern vom Webserver.
Apache wertet diese Angabe aus - egal ob unter UNIX oder unter Win32.Sicher, daß unter UNIX diese Angabe von Apache und nicht doch von der Shell ausgewertet wird?!!!
Zu Perl-CGI unter Apache unter DOS ist auch irgendwie keine wirklich gute Info zu finden,
Reden wir von DOS oder von Win32? Bitte zukünftig präzise Angaben ...Egal. Ich habe weder in der Apache Doku,
noch in der FAQ oder sonstwo eine Aussage
dazu gefunden, was Apache unternimmt um
Scripts ausführen zu lassen. Da Dateitypen,
die unter DOS sowieso ausführbar sind (EXE, BAT) problemlos laufen, dachtich halt, daß Apache irgendwie nicht so viel unternimmt.Selbstverständlich.
Da Du bereits den Perl-Interpreter über den PATH adressieren kannst, würde ich "#!perl" in die 1. Zeile des Skripts schreiben. Bei mir daheim (Windows95) funktioniert das mit Apache 1.3.2.Und wenn du die Scripts dann auf den produktiven Server im Netz kopierst?
Also habich nu perl.exe nach d:\usr\bin kopiert,
und schon ist alles portierbar.Und genau das hasse ich.
Ich will mein Perl-Skript durch einen Doppelklick in den Editor laden können, um schnell etwas darin ändern zu können. Das kann ich aber nicht, wenn der Webserver mich dazu zwingt, *.pl mit dem Perl-Interpreter zu verbinden.Ich benutze Perl auch für richtige Anwendungen, und die werden eben durch Doppelklick gestartet. Für den Editor gibts dann, wie bei Batchdateien, die rechte Maustaste. Und für die Ausführung von Perl-Scripts unter DOS ist diese Shebangangabe total egal. Man kann sie sogar weglassen.
Aber nun ist ja zum Glück alles klar.
-
#!/usr/bin/perl
Guter Witz! Die wird nämlich unter DOS nicht ausgewertet.
Ob diese Anweisung ausgewertet wird, das hängt nicht vom Betriebssystem ab, sondern vom Webserver.
Apache wertet diese Angabe aus - egal ob unter UNIX oder unter Win32.
Sicher, daß unter UNIX diese Angabe von Apache und nicht doch von der Shell ausgewertet wird?!!!Ja, bin ich. Unter UNIX wird keine shell dafür gestartet, sondern bloß ein system()-call oder etwas Ähnliches ausgeführt. Das ist zwar performant, hat aber den Nachteil, daß hier der Inhalt der Variablen PATH nicht verwendbar ist (deshalb *muß* "/usr/local/bin/perl" dort stehen, selbst wenn "/usr/local/bin" im PATH definiert wäre).
Ich benutze Perl auch für richtige Anwendungen, und die werden eben durch Doppelklick gestartet. Für den Editor gibts dann, wie bei Batchdateien, die rechte Maustaste. Und für die Ausführung von Perl-Scripts unter DOS ist diese Shebangangabe total egal. Man kann sie sogar weglassen.
Ich benutze Perl auch für "richtige" Anwendungen (etwa dafür, daheim eine site map meiner Homepage zu generieren, weil ich kein CGI-Recht auf meinem Homepageserver habe ...), aber in diesem Falle leiste ich mir den Luxus, eine Batch-Datei anzulegen, die die Zeile "perl <scriptname>" enthält. (perl selbst habe ich ja im PATH.) Und diese Batch-Datei kann ich durch Doppelklicken starten, während ich mein Skript weiterhin durch Doppelklicken bearbeiten kann ...
-
-
-
hi!
was ist eine Shebang-Angabe?
#!/usr/bin/perl
Guter Witz! Die wird nämlich unter DOS nicht ausgewertet.Aber von Apache, und darum ging es.
bye, Frank!
-
-
-
-
-
Hallo,
jetzt funzen alle Scripts! Es fehlte bei der Ausgabe eines Strings immer der HTML-Header.
Vielen Dank an alle, die mir versucht haben zu helfen, und die mir geholfen haben.
MfG Florian Auer