Michael Schröpl: (PERL)(Apache) Ausgabe eines CGI-Skripts bricht ab

Hi Leute,

ich habe mir gestern ein relativ triviales CGI-Skript in Perl geschrieben, welches

  • eine Datei einliest,
  • die Zeilenreihenfolge umkehrt und
  • die Datei mit <PRE> formatiert ausgibt.
    (Sinn der Sache: Ich will die letzte Änderung
    einer sehr großen, hinten verlängerten
    Protokolldatei - nämlich dem Apache-Log -
    gleich als erstes sehen können.)

Standalone mit Perl aufgerufen funktioniert das
Skript *tadellos*. (access_log ist 160 kb groß.)

Aktiviere ich es aber via CGI über den Webserver, dann gibt es ungefähr 150 Zeilen aus und bricht dann mitten in der Zeile (reproduzierbar an derselben Stelle) ab.
Der Effekt tritt mit jeder von vier verschiedenen ASCII-Dateien auf (drei Apache-Logs, eine eigene ähnliche Log-Datei).

Ich verwende Apache 1.3.6 auf SUN OS; andere (eigene) CGI-Anwendungen funktionieren tadellos
(produzieren aber auch weniger Ausgabedaten).
An der Standardkonfiguration habe ich nichts
Wesentliches gedreht, eigentlich nur mir ein
CGI-Verzeichnis eingerichtet und mit ScriptLog
den CGI-Trace eingeschaltet.

Hat vielleicht irgendjemand eine Idee, was ich da verkehrt mache?
Es riecht ein wenig nach irgendeinem Pufferüberlauf oder so etwas ... es kommt aber
auch *gar* keine Fehlermeldung im Apache-ErrorLog,  nicht mal in der CGI-Trace-Datei ...

Das Perl-Skript:

#! /usr/local/bin/perl

umgekehrt sortierte Anzeige einer Protokolldatei

use strict;
use CGI;
use FindBin;
my $local       = $FindBin::Bin;
my $shared      = "$local/../shared";
my $ApacheLog   = "$local/../../../apache/logs";

(zum Adressieren der Protokolldateien)

require "$shared/html.pl";

(Schmacko-Funktionen für HTML-Kopf und -Ende)

CGI-Parameter auswerten

my $cgi_param = new CGI;
my $type     = $cgi_param->param ("type");
my $pathname = "???";
my $file     = "???";
my $text     = "???";
if ($type eq "ApacheAccess")
   {
     $file = "Apache-Dokumentzugriffe";
     $text = "Hier vermerkt der <CITE>Apache</CITE>-Webserver jeden Zugriff auf eine von ihm gelieferte Seite.";
     $pathname = "$ApacheLog/access_log"
   };

... dasselbe für andere Werte ebenfalls ...

#-------------------------------------------------

Dokumentkopf ausgeben

html::head ($file);
print "<H1>$file</H1>\n";
print "<P><SMALL>$text</SMALL></P>\n";
#------------------------------------------------

Wurde via CGI ein passender Typ angegeben?

if ($file eq "???")
        {
          #--------------------------------------
          # Fehlermeldung ausgeben
          print "<P>Ungültiger Parameterwert <TT>type='$type'</TT></P>\n"
          #--------------------------------------
        }
   else
        {
          #--------------------------------------
          # Inhalt der Protokolldatei einlesen
          open (LOGFILE, "<$pathname");
          my @inhalt = <LOGFILE>;
          close (LOGFILE);
          #--------------------------------------
          # Inhalt der Datei umgekehrt ausgeben
          print "<PRE>\n";
          foreach my $zeile (reverse @inhalt)
                  { print "$zeile"; }
          print "</PRE>\n";
          #---------------------------------------
        }
#-------------------------------------------------

Dokumentende ausgeben

html::tail ();
#=================================================

  1. Hallo,

    Hat vielleicht irgendjemand eine Idee, was ich da verkehrt mache?
    Es riecht ein wenig nach irgendeinem Pufferüberlauf oder so etwas ... es kommt aber
    auch *gar* keine Fehlermeldung im Apache-ErrorLog,  nicht mal in der CGI-Trace-Datei ...
    ...
    Das Perl-Skript:

    »»  ...

    foreach my $zeile (reverse @inhalt)
                      { print "$zeile"; }

    Keine Ahnung, was daran falsch sein soll - aber, wenn es tatsächlich ein Pufferüberlauf sein sollte (wobei ein "Pufferüberlauf" in der Küche noch ganz anders "riechen" kann <g>), würde ich als erstes probieren, die beiden 'my' - Keywords aus dem Skript zu entfernen - sind ja nicht so dringend nötig oder?

    Mal ne Frage am Rande - das Konstrukt "foreach my $var { ... } " habe ich noch nirgendwo vorher so gesehen - wenn man stattdessen "foreach $var { ... }" schreibt, ist $var dann lokal oder global gültig?

    Viele Grüße

    Andreas

    1. Hi,

      foreach my $zeile (reverse @inhalt)
                        { print "$zeile"; }

      Keine Ahnung, was daran falsch sein soll - aber, wenn es tatsächlich ein Pufferüberlauf sein sollte (wobei ein "Pufferüberlauf" in der Küche noch ganz anders "riechen" kann <g>), würde ich als erstes probieren, die beiden 'my' - Keywords aus dem Skript zu entfernen - sind ja nicht so dringend nötig oder?

      bei use strict schon ;-)

      Mal ne Frage am Rande - das Konstrukt "foreach my $var { ... } " habe ich noch nirgendwo vorher so gesehen - wenn man stattdessen "foreach $var { ... }" schreibt, ist $var dann lokal oder global gültig?

      global. Aber vielleicht hilft ja
      print reverse @inhalt;
      ohne foreach; oder nimm eine for-Schleife mit $#inhalt bis 0 (vielleicht hakt ja das reverse, obwohl, kann ich mir nicht vorstellen...)

      Kann man das in der Praxis mal verifizieren (URL)? Oder sind die Daten vertraulich?

      Cheatah

      1. als erstes probieren, die beiden 'my' - Keywords aus dem Skript zu entfernen - sind ja nicht so dringend nötig oder?
        bei use strict schon ;-)

        Ohne "user strict" und den Zwang, wenigstens meine Variablen deklarieren zu müssen (und Funktionsprototypen), würde ich es nicht wagen, in einer solchen Hackersprache wie Perl Anwendungen von einigen tausend lines of code zu schreiben. (Das ist auch so schon "spannend" genug, wenn man eigentlich Turbo-Pascal liebt ...)

        Aber vielleicht hilft ja
        print reverse @inhalt;
        ohne foreach; oder nimm eine for-Schleife mit $#inhalt bis 0 (vielleicht hakt ja das reverse, obwohl, kann ich mir nicht vorstellen...)

        ... zumal es auf der Kommandozeile ja funktioniert .
        Habe ich aber sofort eingebaut (macht das Programm übersichtlicher, danke), hilft leider nicht.
        Ich denke eher, daß es am Webserver oder seiner Konfiguration liegen dürfte ...

        Kann man das in der Praxis mal verifizieren (URL)? Oder sind die Daten vertraulich?

        Leider ist das alles bloß intern. (Ich käme technisch gar nicht an der bösen Firewall vorbei ...)
        Ich bastele gerade an der CGI-Oberfläche für einen Webserver, der als eine Art Operator-Konsole zur Überwachung von etwa 50 Anwendungsservern mit unserer Software dienen soll, die jeweils inhouse bei diversen Kunden betrieben wird, für die wir aber Fernadministration (UNIX und Anwendung) machen müssen - die Anwendungsserver "reden" via X.25 (proprietär) mit meinem Webserver (schicken via cron getriggert Zustandsberichte, der aber wiederum überall hier im Firmen-Intranet von allen autorisierten Operateuren erreichbar sein soll ...

        1. Hi,

          Ohne "user strict" und den Zwang, wenigstens meine Variablen deklarieren zu müssen (und Funktionsprototypen), würde ich es nicht wagen, in einer solchen Hackersprache wie Perl Anwendungen von einigen tausend lines of code zu schreiben. (Das ist auch so schon "spannend" genug, wenn man eigentlich Turbo-Pascal liebt ...)

          *lol* Ja, von TP unterscheidet sich Perl doch ein "wenig" :-)))

          ohne foreach; oder nimm eine for-Schleife mit $#inhalt bis 0 (vielleicht hakt ja das reverse, obwohl, kann ich mir nicht vorstellen...)

          ... zumal es auf der Kommandozeile ja funktioniert .

          Tja, aber man weiß ja nie.

          Habe ich aber sofort eingebaut (macht das Programm übersichtlicher, danke), hilft leider nicht.
          Ich denke eher, daß es am Webserver oder seiner Konfiguration liegen dürfte ...

          Das ist leider nicht mein Spezialgebiet, aber irgendwie kann ich mir das nicht vorstellen. Aber vielleicht hilft es ja schon, das Logfile am Anfang einmal zu kopieren und auf die Kopie zuzugreifen.

          Noch 'ne Idee:
          Gib doch mal am Anfang des Dokuments (nach dem Einlesen der Datei) folgendes aus:

          print "Dateigröße: " . (-s $pathname) . "<BR>\nEingelesen: " . (length(join('',@inhalt))) . "<BR>\n<BR>\n";

          Auf das Ergebnis bin ich gespannt!

          Cheatah

          1. Noch 'ne Idee:
            Gib doch mal am Anfang des Dokuments (nach dem Einlesen der Datei) folgendes aus:
            print "Dateigröße: " . (-s $pathname) . "<BR>\nEingelesen: " . (length(join('',@inhalt))) . "<BR>\n<BR>\n";
            Auf das Ergebnis bin ich gespannt!

            Dateigröße: 670358
            Eingelesen: 670358

            Das CGI-Skript bricht wirklich bei der Ausgabe ab. Ich sehe ja den HTML-Source des erzeugten Dokuments im Browser, und da fehlt der ganze Rest, inklusive </BODY> und </HTML> ...

            Ich habe das Skript gerade so weit abgemagert, daß es nur noch Zahlen von 1 bis 10000 ausgibt. Auf der Kommandozeile erzeugt es brav seine 59 kB; via CGI kommt es bis 1012 (5103 bytes).

            Ich komme immer mehr zu der Überzeugung, daß mein Apache kaputt ist ... aber wo kriege ich einen her, der funktioniert? (SUN Ultra-1 sparc mit SunOS 5.5, leider ohne C-Compiler - Apache 'maken' könnte ich.)

            1. Hi,

              Ich habe das Skript gerade so weit abgemagert, daß es nur noch Zahlen von 1 bis 10000 ausgibt. Auf der Kommandozeile erzeugt es brav seine 59 kB; via CGI kommt es bis 1012 (5103 bytes).

              Ich komme immer mehr zu der Überzeugung, daß mein Apache kaputt ist ...

              ja, das scheint mir auch so.

              aber wo kriege ich einen her, der funktioniert? (SUN Ultra-1 sparc mit SunOS 5.5, leider ohne C-Compiler - Apache 'maken' könnte ich.)

              http://www.apache.org? Vielleicht ist es aber auch nur eine Einstellungsfrage. Wobei ich gerne wüßte, was _das_ für eine Einstellung sein soll...

              Cheatah

              1. Ich komme immer mehr zu der Überzeugung, daß mein Apache kaputt ist ...
                ja, das scheint mir auch so.
                aber wo kriege ich einen her, der funktioniert? (SUN Ultra-1 sparc mit SunOS 5.5, leider ohne C-Compiler - Apache 'maken' könnte ich.)
                http://www.apache.org?

                Den habe ich gerade geholt und installiert - und herausgefunden, daß es offenbar schon der war, der vorher lief. (rekursives diff über beide Verzeichnisbäume findet keinen Unterschied.) Vielleicht erinnere ich mich ja falsch, und es war der Perl-Interpreter, den ich von der SUN-site habe ...

                Das Problem tritt natürlich immer noch auf.
                Ich habe ein CGI-Shell-Skript geschrieben, das nichts andere als den http-Header und "Hallo" ausgibt. Selbst dieses bricht bei etwa 3 von 10 reload-Versuchen in der Bearbeitung ab. Im Apache-Log steht nichts anderes, als daß das Ding mal 7 Byte und mal 0 Byte ("Das Dokument enthält keine Daten" für Netscape3) ausgibt ... was ist das nur für eine brüchiger Kiste, diese SUN?

                Vielleicht ist es aber auch nur eine Einstellungsfrage. Wobei ich gerne wüßte, was _das_ für eine Einstellung sein soll...

                Ich auch.

                Ich verwendet die Original-Apache-httpd.conf-Datei und habe dort am Ende eine include-Anweisung auf meine eigenen Erweiterungen eingefügt. Das sind nicht viele (hoffentlich ist es nach dem Umbruch noch lesbar):

                #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
                #@@ FIMSview.conf -- Apache HTTP server configuration file extension for FIMSview @@@
                #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

                ######################################

                Basiseigenschaften des Servers

                ######################################

                #------------------------------------------------------------------------------

                Port: The port to which the standalone server listens. For

                ports < 1023, you will need httpd to be run as root initially.

                Port 8080

                (MS) Zum Testen erst mal nicht "80" - dafür bräuchte ich root-Berechtigung

                #------------------------------------------------------------------------------

                User/Group: The name (or #number) of the user/group to run httpd as.

                User  fimsview
                Group staff

                (MS) Das ist die normale FIMSview-Betriebskennung

                #------------------------------------------------------------------------------

                ServerAdmin: Your address, where problems with the server should be

                e-mailed.  This address appears on some server-generated pages, such

                as error documents.

                ServerAdmin michael.schroepl@telekurs.com

                (MS) Das bin vorerst mal ich selbst

                #------------------------------------------------------------------------------

                ServerName allows you to set a host name which is sent back to clients for

                your server if it's different than the one the program would get (i.e., use

                "www" instead of the host's real name).

                Note: You cannot just invent host names and hope they work. The name you

                define here must be a valid DNS name for your host. If you don't understand

                this, ask your network administrator.

                If your host doesn't have a registered DNS name, enter its IP address here.

                You will have to access it by its address (e.g., http://123.45.67.89/)

                anyway, and this will make redirections work in a sensible way.

                ServerName tkdfims6

                (MS) Der Server ist zu doof, das selbst herausfinden zu können ...

                #------------------------------------------------------------------------------

                HostnameLookups: Log the names of clients or just their IP addresses

                e.g., www.apache.org (on) or 204.62.129.132 (off).

                The default is off because it'd be overall better for the net if people

                had to knowingly turn this feature on, since enabling it means that

                each client request will result in AT LEAST one lookup request to the

                nameserver.

                HostnameLookups On

                (MS) Das halten wir aus - ich will Transparenz meiner Besucher!

                #------------------------------------------------------------------------------

                Etwas mehr Berechtigungen im URL-Baum:

                <Directory />
                    Options       IncludesNOEXEC SymLinksIfOwnerMatch
                    AllowOverride AuthConfig FileInfo Indexes Limit
                </Directory>

                So ziemlich alles bis auf CGI einschalten ...

                #------------------------------------------------------------------------------

                ###################################

                CGI für FIMSview-Einbettung

                ###################################

                #------------------------------------------------------------------------------

                Alias names

                Alias       /     "/export/one/d/fimsview/web/"

                (MS) FIMSview-Wurzelverzeichnis

                #------------------------------------------------------------------------------

                FIMSview-CGI-Verzeichnis

                ScriptAlias /cgi/ "/export/one/d/fimsview/web/cgi/"
                <Directory "/export/one/d/fimsview/web/cgi/">
                Options    ExecCGI

                (MS): Ich will meine FIMSview-Installation irgendwohin legen können.

                #       Insbesondere auch außerhalb des normalen Apache-URL-Baums ...
                  AddHandler cgi-script .pl

                (MS) Erlaubt mir, HTML- und CGI-Dateien gemeinsam im FIMSview-Verzeichnis zu halten

                </Directory>
                #------------------------------------------------------------------------------
                ScriptLog logs/cgi_log
                ScriptLogBuffer 99999

                (MS): Separates Fehlerprotokoll für CGI-debugging

                #------------------------------------------------------------------------------

                1. Hi,

                  Das Problem tritt natürlich immer noch auf.

                  merkwürdig. Kann ich nichts weiter zu sagen, Server sind nicht meine Stärke.

                  Ich verwendet die Original-Apache-httpd.conf-Datei und habe dort am Ende eine include-Anweisung auf meine eigenen Erweiterungen eingefügt. Das sind nicht viele (hoffentlich ist es nach dem Umbruch noch lesbar):

                  Sagt mir leider nichts :-) aber vielleicht kann ja jemand anders etwas damit anfangen.

                  Cheatah

      2. Mal ne Frage am Rande - das Konstrukt "foreach my $var { ... } " habe ich noch nirgendwo vorher so gesehen - wenn man stattdessen "foreach $var { ... }" schreibt, ist $var dann lokal oder global gültig?

        global.

        Sorry, Cheata, aber wenn ich mich <alzheimer> recht entsinne </alzheimer>, dann ist eine foreach-var immer lokal zu dem Block, den das foreach einschließt. Quelle: Farid Hajji (kein Tippfehler!) "Perl", Addison-Wesley (imvho ein wirklich gutes Buch für Anfänger + Runaways).

        Ciao
          K@rl

        1. Hi,

          Sorry, Cheata, aber wenn ich mich <alzheimer> recht entsinne </alzheimer>, dann ist eine foreach-var immer lokal zu dem Block, den das foreach einschließt. Quelle: Farid Hajji (kein Tippfehler!) "Perl", Addison-Wesley (imvho ein wirklich gutes Buch für Anfänger + Runaways).

          Du kannst $var aber noch nach dem foreach auslesen bzw. weiterverwenden. Das ist u.a. dann sinnvoll, wenn man die Schleife vorzeitig abbricht.

          Cheatah

  2. Aktiviere ich es aber via CGI über den Webserver, dann gibt es ungefähr 150 Zeilen aus und bricht dann mitten in der Zeile (reproduzierbar an derselben Stelle) ab.
    Der Effekt tritt mit jeder von vier verschiedenen ASCII-Dateien auf (drei Apache-Logs, eine eigene ähnliche Log-Datei).

    ... weitere Details:

    • Es hängt nicht vom verwendeten Browser ab.

    • Egal, wie groß die anzuzeigende Datei ist, es werden immer ungefähr 5 kB übertragen (schwankt nur um ca. 100 Byte, ist aber pro Dokument konstant).

    • Wenn ich die 160-kb-Datei ins Wurzelverzeichnis des Webservers kopiere und direkt als URL anspreche, zeigt der sie mir rasend schnell (Intranet) und vollständig an ...

    Wo ist dieser 5kb-Engpaß in meiner CGI-Schnittstelle? Heul ... :-(

    1. Hallo Michael!

      • Wenn ich die 160-kb-Datei ins Wurzelverzeichnis des Webservers kopiere und direkt als URL anspreche, zeigt der sie mir rasend schnell (Intranet) und vollständig an ...

      Mmh, und wenn Du die Datei ueber ein Script ausgeben laesst, aber das reverse weglaesst, also einfach
          print @inhalt;
      machst? Kommt dann die Datei ganz durch oder auch nur 5kB?

      Calocybe

      1. Mmh, und wenn Du die Datei ueber ein Script ausgeben laesst, aber das reverse weglaesst, also einfach
            print @inhalt;
        machst? Kommt dann die Datei ganz durch oder auch nur 5kB?

        Auch nur 5kB. (5232, 5158, 5142 bzw. 5150 Byte.)
        Wie gesagt: Über die Kommandozeile funktioniert es, über CGI funktioniert es nicht.

        1. Hallo,

          Mmh, und wenn Du die Datei ueber ein Script ausgeben laesst, aber das reverse weglaesst, also einfach
          »»     print @inhalt;
          machst? Kommt dann die Datei ganz durch oder auch nur 5kB?

          Auch nur 5kB. (5232, 5158, 5142 bzw. 5150 Byte.)

          seltsam... habe gerade mal den Teil des Skriptes, der die Datei einliest und die Ausgabe macht unter Apache 1.3.3-1 (Linux) mit einer 120 kB großen Datei und der /var/log/httpd/apache_log getestet. Funktioniert - auch mit den besagten 'my's und dem use strict... Womöglich sind bei Dir in der Apache-Konfiguration irgendwelche Begrenzungen eingestellt? Hat das CGI-Trace damit irgendwas zu tun? Oder stört sich das System daran, daß durch den CGI-Aufruf ein neuer Eintrag in die apache_log kommt, während das Skript womöglich noch daraus liest?

          Viel Glück beim Debuggen und

          bis dannundwann...

          Andreas

          1. machst? Kommt dann die Datei ganz durch oder auch nur 5kB?
            Auch nur 5kB. (5232, 5158, 5142 bzw. 5150
            seltsam... Womöglich sind bei Dir in der Apache-Konfiguration irgendwelche Begrenzungen eingestellt?

            Das vermutete ich auch - aber die Konfiguration ist der der Standardauslieferung, da ist keine Puffergröße von 5 KB zu sehen.

            Ich habe den Apache nicht selbst compiliert (weil ich auf der SUN keinen C-Compiler habe - den müßte man extra kaufen), sondern mir von der Sun-Homepage für PD-Software die Binary-Form als SunOS-package geholt und hier vom Systemadministrator installieren lassen. Da könnten vielleicht irgendwelche komischen Compiler-Optionen eingebrannt sein - aber ich denke eigentlich, das müßte bekannt sein, die Quelle war ja schließlich nicht irgendwer, sondern SUN selbst ...

            Hat das CGI-Trace damit irgendwas zu tun?

            Den habe ich gerade abgeschaltet - nein, leider war es das auch nicht. (Das wäre ja auch noch schöner, wenn ausgerechnet der CGI-Trace die Ausführung von CGI-Programmen behindern würde ...)

            Oder stört sich das System daran, daß durch den CGI-Aufruf ein neuer Eintrag in die apache_log kommt, während das Skript womöglich noch daraus liest?

            Dann würde es ja bei der Anzeige der vierten Datei, nämlich meiner Anwendungs-Logfile, funktionieren müssen - die wächst nur ab und zu mal um eine Zeile, und dies unabhängig von Webserver-Zugriffen.

  3. Hallo,

    ich habe dein Beispiel mal bei mir installiert und getestet.

    Die einzigen Veränderungen, die ich durchgeführt habe, waren Pfad anpassen und die html-Tools auskommentiert.

    Meine Log-Datei (785 kb, 35000 Zeilen) wurde wie gewünscht in umgekehrter Reihenfolge angezeigt.

    Mein Webserver Apache/1.3.0 (UNIX) Debian/GNU, built: Jun 11 1998.

    Also ich würde sagen, es liegt nicht am Skript.

    Gruß Hansi

  4. Hallo,

    ... einer sehr großen ... Standalone mit Perl ... funktioniert ... *tadellos* ...
    ... via ... Webserver ...ungefähr 150 Zeilen ... und bricht ... ab ...

    ich hatte einmal ein ähnliches Verhalten als ich ein Script für Hessen tanzt schrieb. Nach ca. 1,6 KB Filegröße beim umkopieren war auf dem Webserver das Ende des deterministischen Verhaltens erreicht. Mein Problem damals, war mein nicht weit genug ausgereiftes Verständnis von Perl.

    Ich vermute, daß dies hier auch vorliegt. Die Zeile

    ... my @inhalt = <LOGFILE>; ...

    evaluiert in einem Listenkontext. Dies bedeutet, daß das gesamte in einem Rutsch in das Array eingelesen wird. Dies bedeutet, Perl muß dem System Speicherplatz > 160Kbyte abfordern. Dies wahrscheinlich nicht am Stück, da nicht bekannt sein dürfte wie groß das File ist, und Perl intern eine Leseschleife aufmacht (Dies wahr eine Vermutung aus dem Verhalten) Dies ist normalerweise in heutigen Systemen als eingenständiges Programm kein Problem. In einem Webbrowserumfeld, hängt es aber von dessen Umfeld (Belastung, Konfiguration, Hersteller :-), Uhrzeit, Gezeiten oder was auch immer) ab, ob eine solche Anforderung durchgeht oder nicht.

    Meine Zeile damals war: "print OUTFILE <INFILE>;". Erst mit "while (<INFILE>) { print OUTFILE; }" funktioniere es dann. Im ersten Fall hatte ich einen Listenkontext, mit dem erfolg des nicht mehr reproduzierbaren Verhaltens. Im zweiten Fall, dem skalaren Kontext ging dann alles wie am Schnürchen (ich schreibe dies alles aus dem Gedächtnis, es kann also sein, daß meine Perl-Fragmente nicht ganz richtig sind. Ich hoffe jedoch den Unterschied im Speicherbedarf der beiden Kontexte verdeutlicht zu haben).

    Wenn ich richtig liege, wird es Dir wahrscheinlich trotzdem nicht helfen, da Du ja die Reihenfolge umdrehen willst, und deswegen höchstwahrscheinlich gezwungen bist alles in den Speicher zu laden.

    Ciao.

    PS.:
    Sicherlich sinnvolle Anschaffungen sind die Perl-Bücher aus dem Hause O'Reilly.
    PERL: Für Anfänger
    PERL, Das Kochbuch: Interessant
    PERL für Runaways: (Sorry: Fortgeschrittene Perl Programmierung) Sehr interessant. Ich habe die Beispiel Fragmente meistens nicht (auf Anhib) verstanden. Aber die Info, was mit Perl alles möglich ist - und in welcher Kürze - einfach sagenhaft.

    1. Ich vermute, daß dies hier auch vorliegt. Die Zeile

      ... my @inhalt = <LOGFILE>; ...
      evaluiert in einem Listenkontext. Dies bedeutet, daß das gesamte in einem Rutsch in das Array eingelesen wird. Dies bedeutet, Perl muß dem System Speicherplatz > 160Kbyte abfordern. Dies wahrscheinlich nicht am Stück, da nicht bekannt sein dürfte wie groß das File ist, und Perl intern eine Leseschleife aufmacht (Dies wahr eine Vermutung aus dem Verhalten)

      Das Skript bricht leider auch ohne hohe Speicheranforderung ab (etwa wenn ich bloß aufsteigende Zahlen von 1 bis 10000 ausgebe, siehe Posting an Cheatah).

      Zudem beweist die von Cheatah vorgeschlagene Diagnoseausgabe, daß das Einlesen funktioniert ...