nicht angemeldet
Parallele Verarbeitung
0 0 0 0 Die Lösung
Parallele Verarbeitung
Hallo!
Ich habe ein Forumsscript (Perl) um eine Funktion zur E-Mail-Benachrichtigung erweitert. Wenn jemand eine Nachricht abschickt, werden zuerst die üblichen Vorgänge (Posting speichern, Zähler erhöhen, etc.) erledigt. Danach wird eine Subroutine aufgerufen, die eine Bestätigungseite erzeugt und anzeigt. Ganz zum Schluß erfolgt der E-Mail-Versand, ebenfalls über eine Subroutine.
Mein Problem ist jetzt, daß die Bestätigungsseite erst angezeigt wird, wenn alle Mails verschickt sind. Das dauert etwas und es kommt dadurch zu jeder Menge Doppelpostings. Wie kann ich die Bestätigungsseite vor dem Mailversand anzeigen? Muß ich dazu ein separates Script für den Mailversand verwenden und wenn ja, wie rufe ich ein PerlScript aus einem PerlScript auf, damit es parallel abgearbeitet wird? Für hilfreiche Tips wäre dankbar.
Viele Grüße
Harald
-
morgens,
Mein Problem ist jetzt, daß die Bestätigungsseite erst angezeigt wird, wenn alle Mails verschickt sind. Das dauert etwas und es kommt dadurch zu jeder Menge Doppelpostings.
Schwierig. Und wenn es wirklich "jede Menge" Doppelpostings gibt, ist dein Forum besser und häufiger besucht als das Forum hier.
Wie kann ich die Bestätigungsseite vor dem Mailversand anzeigen?
Solange niemand dein Script im Detail kennt, ist das schwer einzuschätzen. Zunächst scheint da ein Widerspruch vorzuliegen. Du schreibst:
... wird eine Subroutine aufgerufen, die eine Bestätigungseite erzeugt und anzeigt. Ganz zum Schluß erfolgt der E-Mail-Versand
und unmittelbar danach sagst du,
daß die Bestätigungsseite erst angezeigt wird, wenn alle Mails verschickt sind
Also, was passiert nun wirklich zuerst: die Bestätigung oder der mail-Versand?
Grundsätzlich könntest du mit einem "lock"-file dafür sorgen, daß derjenige, der gerade geschrieben hat, keine Doppelpostings absenden kann und erst wieder schreibberehctigt ist, wenn alle anderen anstehenden Vorgänge einschließlich mail-Versand erledigt sind.Muß ich dazu ein separates Script für den Mailversand verwenden
Nein, nicht zwingend. Schaden kanns aber auch nix.
wie rufe ich ein PerlScript aus einem PerlScript auf
Mit "include" oder "require"
In deinem Fall wärs wahrscheinlich günstiger, mit einer if/else-Abfrage nachzuschauen, ob der mail-Versand erledigt ist und dann erst die "Bestätigung" anzeigen zu lassen.
Das größte Problem "könnte" (mit sehr vielen Fragezeichen) sein, daß bei der Frequenz, mit der dein Forum besucht wird, ganz einfach dein "Posteingang" beim mail-Provider überläuft. Das ist unwahrscheinlich, aber nicht unmöglich.
Grüße aus Berlin
Christoph S.
-
Morgen,
erstmal danke für deine Bemühungen.
Schwierig. Und wenn es wirklich "jede Menge" Doppelpostings gibt, ist dein Forum besser und häufiger besucht als das Forum hier.
Präziser: Jede Menge im Verhältnis zum Posting-Aufkommen, also etwa 25-30%.
Also, was passiert nun wirklich zuerst: die Bestätigung oder der mail-Versand?
Zuerst die Bestätigung, dann der Mailversand. Offenbar erfolgt die HTML-Ausgabe erst, wenn das komplette Script abgearbeitet ist.
Es handelt sich im großen und ganzen um das Script WWWBoard von Matt Wright. Der Mailversand erfolgt am Ende des Script mit folgender Subroutine:
sub mail_list {
open(LIST,"$cgi_dir/$list_file");
@addresses=<LIST>;
close(LIST);
foreach $member(@addresses) {
open (MAIL, "|$mailprog $member") || die "Fehler beim Öffnen von $mailprog!\n";
print MAIL "From: $recipient\n";
print MAIL "Subject: $title: $subject\n";
print MAIL "To: $member\n";print MAIL "Es gibt eine neue Nachricht im\n";
print MAIL "$title: $baseurl/ \n";
print MAIL "Die Nachricht "$subject" wurde geschrieben\n";
print MAIL "von $name, am $long_date";
if ($followup == 1) {
print MAIL ",\nals Antwort auf "$origsubject", geschrieben\n";
print MAIL "von $origname, am $origdate";
}
print MAIL ".\n";
print MAIL "============================================================\n\n";
print MAIL "$FORM{'body'}\n\n";
print MAIL "============================================================\n";
print MAIL "Diese E-Mail wurde automatisch erstellt. Wenn Sie auf\n";
print MAIL "diese Nachricht antworten wollen, gehen Sie bitte zum\n";
print MAIL "$title: $baseurl/ \n\n";
print MAIL "Falls Sie sich aus der Mailingliste austragen wollen, gehen\n";
print MAIL "Sie bitte ebenfalls zum $title.\n";close (MAIL);
$x++;
}
}Grundsätzlich könntest du mit einem "lock"-file dafür sorgen, daß derjenige, der gerade geschrieben hat, keine Doppelpostings absenden kann und erst wieder schreibberehctigt ist, wenn alle anderen anstehenden Vorgänge einschließlich mail-Versand erledigt sind.
Wenn möglich, möchte ich zuerst die Ursache bekämpfen.
wie rufe ich ein PerlScript aus einem PerlScript auf
Mit "include" oder "require"Könnte ich mal ausprobieren. Allerdings dachte ich immer, ein mit "require" eingebundenes Script verhält sich genauso, als würde es direkt im Hauptscript stehen. Wenn dem so ist, ändert sich nichts.
In deinem Fall wärs wahrscheinlich günstiger, mit einer if/else-Abfrage nachzuschauen, ob der mail-Versand erledigt ist und dann erst die "Bestätigung" anzeigen zu lassen.
Genau das will ich nicht. Der Versand der z. Z. etwa 40 Mails dauert 30-40 Sek. Das ist für viele zu lange und es kommt zu nervösen Zuckungen im Klickfinger (trotz dem Hinweis "Bitte nur einmal klicken und warten").
Mein Problem ist, daß der Mailversand zu lange dauert und HTML-Ausgaben offenbar erst nach Beenden des Script ausgegeben werden, egal wo sie im Script stehen bzw. wann sie erzeugt werden.
Eine Lösung, die mir vorschwebt sieht so aus:
1. Die Mail nicht direkt versenden, sondern in eine Datei schreiben.
2. Über einen Systemaufruf ein Perlscript starten, daß diese Datei an die Teilnehmer der Mailingliste
verschickt.Leider weiß ich nicht, ob es so funktioniert bzw. ob es nicht eine viel einfachere Lösung gibt.
Viele Grüße
Harald-
Moin!
Es handelt sich im großen und ganzen um das Script WWWBoard von Matt Wright. Der Mailversand erfolgt am Ende des Script mit folgender Subroutine:
Der Mailversand ist suboptimal geregelt. Du versendest an alle betroffenen Mailadressen eine einzelne Mail. Das ist zwar schön für die Empfänger, aber schlecht für dich.
Pack die Empfängeradressen alle in _eine_ Mail rein, ins BCC-Feld. Dann schickst du genau _eine_ Mail ab, vielleicht (wenn zuviele Mailadressen zu bedienen sind - ich würde bei 20 bis 30 Addressen im BCC irgendwann Schluß machen) eine zweite Mail.
Bedenke, dass diese Wartezeit auch ein nicht uninteressanter Ansatzpunkt für DoS-Angriffe auf deinen Server bzw. dein Forum ist. Was lange Zeit benötigt, ist interessant. Hier auf dem SelfServer ist zum Beispiel die Suche interessant zum DoSsen - klappt nur zum Glück immer weniger, weil da nach und nach Riegel vorgeschoben wurden. :)
Alternativ könntest du die zu sendenden Mails vom Posting-Skript aus auch erstmal nur in eine Warteschlange stellen, die von einem Cronjob abgearbeitet wird. Das dürfte aber nicht ganz so trivial sein.
- Sven Rautenberg
--
ss:) zu:) ls:[ fo:} de:] va:) ch:] sh:) n4:# rl:| br:< js:| ie:( fl:( mo:| -
Also, was passiert nun wirklich zuerst: die Bestätigung oder der mail-Versand?
Zuerst die Bestätigung, dann der Mailversand. Offenbar erfolgt die HTML-Ausgabe erst, wenn das komplette Script abgearbeitet ist.
Ich bin nicht sicher ob das deine Probleme löst, aber vielleicht hilft's ja
http://search.cpan.org/author/JIMT/Mail-Bulkmail-3.09/Bulkmail.pmStruppi.
-
-
-
Hallo Harald!
Dein Problem fasse ich so zusammen: Die Bestätigung für den Browser setzt Du ab, sie wird aber vorerst nicht angezeigt, sondern erst viel später (dann wenn die Leute schon ein zweites Mal auf "abschicken" gegangen sind). Die Ausgabe wird als gecacht und erfolgt nicht "Zeichen für Zeichen". Richtig? Das hatte ich einige wenige Postings vorher schon mal gefragt. Eine Lösung scheint es bei der Funktion "autoflush" zu liegen. Probleme kann aber auch Dein PRovider machen (wie es bei mir scheint), der die Übertragung selbst nocheinmal cachet. Weit bin ich noch nicht gekommen, aber suche mal in Google unter "autoflush +perl", da gibts einige Links...
Sag mal, wie Du es machst!
Gruß!MArtin
-
Halihallo Harald
Mein Problem ist jetzt, daß die Bestätigungsseite erst angezeigt wird, wenn alle Mails verschickt sind. Das dauert etwas und es kommt dadurch zu jeder Menge Doppelpostings. Wie kann ich die Bestätigungsseite vor dem Mailversand anzeigen? Muß ich dazu ein separates Script für den Mailversand verwenden und wenn ja, wie rufe ich ein PerlScript aus einem PerlScript auf, damit es parallel abgearbeitet wird? Für hilfreiche Tips wäre dankbar.
Der Mailversand dauert IMHO am längsten. Solange STDOUT offen bleibt, wird die Ausgabe
gecached. Eine Möglichkeit wäre also, die Ausgabe STDOUT zu schliessen und das versenden
des Mails anschliessend durchzuführen. Somit sollte die Ausgabe dann im Browser er-
scheinen. Ein paralleles Abarbeiten oder zweites Script halte ich nicht für notwendig.Viele Grüsse
Philipp
--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.-
Hi Philipp!
Eine Möglichkeit wäre also, die Ausgabe STDOUT zu schliessen und das versenden des Mails anschliessend durchzuführen.
Danke, klingt gut! Ich werde es sobald wie möglich ausprobieren.
Viele Grüße
Harald-
Eine Möglichkeit wäre also, die Ausgabe STDOUT zu schliessen und das versenden des Mails anschliessend durchzuführen.
Einspruch, euer Ehren!
Das Schließen von STDOUT führt zum sofortigen Abbruch des Perl-Scriptes durch den Apachen! Danach ist eine Fortsetzung des Scriptes nicht mehr möglich und die Ausgabe bleibt unvollständig!
Gruß!
Martin-
Einspruch, euer Ehren!
Einspruch abgelehnt!
Das Schließen von STDOUT führt zum sofortigen Abbruch des Perl-Scriptes durch den Apachen! Danach ist eine Fortsetzung des Scriptes nicht mehr möglich und die Ausgabe bleibt unvollständig!
Ich schließe jetzt STDOUT vor dem Versenden der E-Mails. Die Bestätigungsseite wird nach dem Absenden eines Postings blitzschnell angezeigt und die Mails werden ebenfalls versandt. Ich muß sagen, das Ergebnis überzeugt und wenn die Methode falsch ist, ist sie zumindest sehr gut falsch ;-)
Viele Grüße
Harald-
Hallo Harald,
Ich schließe jetzt STDOUT vor dem Versenden der E-Mails. Die Bestätigungsseite wird nach dem Absenden eines Postings blitzschnell angezeigt und die Mails werden ebenfalls versandt. Ich muß sagen, das Ergebnis überzeugt und wenn die Methode falsch ist, ist sie zumindest sehr gut falsch ;-)
Verstehe ich nicht, bei mir ist der letzte BEfehl, der abgearbeitet wird, das schließen der STDOUT. Danach ist Sense...
Viele Grüße
Martin-
Halihallo Martin
Verstehe ich nicht, bei mir ist der letzte BEfehl, der abgearbeitet wird, das schließen der STDOUT. Danach ist Sense...
Das lässt sich _konfigurieren_, wie so ziemlich alles andere auf der Welt... Wenn du
das nicht willst, erstelle mit fork einen Childprozess und setze setsid, dann läuft er
vollständig getrennt von dem Script (eigene Session), dann wirst du das Problem nimmer
haben.Viele Grüsse
Philipp
--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.-
Halihallo Philipp
das nicht willst, erstelle mit fork einen Childprozess und setze setsid, dann läuft er
vollständig getrennt von dem Script (eigene Session), dann wirst du das Problem nimmer
haben.Und wenn mir der Vater durch irgendetwas stirbt, habe ich einen Zombie? *lach* das macht mein Provider sicher nicht lange mit...
Da habe ich mit meinem Forked-LWPs lange genug getüftelt, daß die sich dann selbst killen, wenn die Pipe mit dem daddy ins Leere geht. Aber so wie Du das schreibst SOLL der Sohn ja autark leben. Wie soll er dann den Zustand des Vaters (damit es keine Zombies gibt) überwachen?
Gruß!
Martin-
Halihallo Martin
Und wenn mir der Vater durch irgendetwas stirbt, habe ich einen Zombie? *lach* das macht mein Provider sicher nicht lange mit...
Hä? - Mag sein, dass ich hier zuwenig informiert bin, aber IMHO interessiert sich
höchstens der Parent für seine Children. Prozessinformationen des Child werden aufbe-
wahrt, sodass der Parent Exist- und andere Stati auslesen kann, obwohl sie schon tot
sind. Um Zombies zu verhindern, gibt's das "reaping children", der Parent wartet auf
das determinieren der Children, sodass diese von der Prozesstable entfernt werden können.Da habe ich mit meinem Forked-LWPs lange genug getüftelt, daß die sich dann selbst killen, wenn die Pipe mit dem daddy ins Leere geht. Aber so wie Du das schreibst SOLL der Sohn ja autark leben. Wie soll er dann den Zustand des Vaters (damit es keine Zombies gibt) überwachen?
Mir ist jedoch schleierhaft, warum dies auch nach setsid von Nöten sein müsste, da der
Prozess aus der Session fällt und eine neue Session bildet. Parent und Child haben hier
IMHO gar keine Bedeutung mehr (der Parent vergisst sein eigenes Child sozusagen).---
Nun, warum schreibst du dir keinen Reaper oder setzt einfach $SIG{CHLD} auf "IGNORE"?
Bei SIGCHLD auf IGNORE, wird dem System mitgeteilt, dass Childstati gar nicht
interessieren und der Prozess sogleich aus der Prozesstable entfernt werden kann.---
Ich wäre sehr froh, wenn mich hier ein Wissender korrigieren könnte oder sagen würde,
dass ich richtig liege, denn ich _weiss es nicht (genau)_.Viele Grüsse
Philipp
--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.-
Hallo Philipp,
ich glaube wir sprechen ein wenig aneinander vorbei (was aber nicht tragisch ist).Ich dachte, Du sagtest: wenn der Apache das Script killt, sobald kein STDOUT mehr existiert (was man tatsächlich auch abstellen kann - nur mein Provider scheinbar nicht), dann laß doch ein Sohn (der ein Dämon, weil autark vom Vater, ist) die Meldung machen (er terminiert sich ja eh selbst) (geht aber nicht, weil der Dämon-Sohn nicht an den Browser des Client kommt). Ich könnte auch den Vater die Meldung an den Browser ausgeben lassen, einen Dämon-Sohn zeugen lassen (klingt schon ordinär...), der den REst abarbeitet und der Vater läßt sich durch den Apachen killen (weil er STDOUT zumacht), nachdem er die Statusmeldung abgegeben hat. Geht aber auch nicht, weil der Dämon-Sohn trotzdem Ergebnisse an den Browser abgeben muß, und dort nicht hinkommt). Der Vater kann diese Meldungen aber via Pipe auch nicht mehr annehmen (wäre die einzige Verbindungsmöglichkeit), weil er nicht mehr exisiert. Wenn der Dämon-Sohn sich jetzt irgendwie festfrißt kann es sein, daß er sich selbst nicht mehr killen kann, und eine übergeordenete Instanz gibt es auch nicht mehr (Vater ist ja schon weg), außer den Administrator meines Providers. Er wäre ein Zombie. Also kann es kein Dämon sein.
Bleibt nur ein normaler Parallelprozess bei dem der VAter als Kontrollinstanz vom Sohn bestehen bleibt und informiert wird, wenn der Sohn terminiert (also kein Dämon), der sohn wird aber ebenfalls gekillt, wenn der VAter vom Apachen umgelegt wird (wenn er versucht den STDOUT zu schliessen). SOmit kann nur der Sohnprozess (kein Dämon) die Statusmeldung ausgeben und sich dann vom Apachen killen lassen (weil er STDOUT zumacht). Geht aber auch nicht, weil der Sohnprozess zwar ein STDOUT besitzt, dieser aber nicht zu Client weist, sondern zum VAter.
Nun, warum schreibst du dir keinen Reaper oder setzt einfach $SIG{CHLD} auf "IGNORE"?
Bei SIGCHLD auf IGNORE, wird dem System mitgeteilt, dass Childstati gar nicht
interessieren und der Prozess sogleich aus der Prozesstable entfernt werden kann.Ich habe aber keinen Zugriff auf die ps. Der REst der Antwort: siehe oben.
Mein Problem ist, daß der Provider die Server-Pufferung nicht abschaltet (kann oder will). Hier liegt scheinbar die Lösungsmöglichkeit (weil eine ungepufferte Ausgabe, wie ich sie will, bei anderen Providern lauft). Im Moment verfolge ich deshalb zwei Möglichkeiten: einen eigenen kleinen http-server zu schreiben (der die Ausgabe ungepuffert über einen eigenen Port leitet), oder die Übertragunsgpakete mit unnützen Daten zu füllen (damit der Puffer geleert werden muß).
Was letzendlich laufen wird, weiß ich noch nicht. Vielleicht lasse ich auch nur via Javascript ein kleines Fenster aufpoppen "Bitte warten" und das dann erst die Perlroutine startet...)
Gruß!
MArtin-
Halihallo Martin
ich glaube wir sprechen ein wenig aneinander vorbei (was aber nicht tragisch ist).
Ja, was mein Fehler ist. Mit setsid bin ich über das eigentliche Thema geschossen ;)
Ich dachte, Du sagtest: wenn der Apache das Script killt, sobald kein STDOUT mehr existiert (was man tatsächlich auch abstellen kann - nur mein Provider scheinbar nicht), dann laß doch ein Sohn (der ein Dämon, weil autark vom Vater, ist) die Meldung machen (er terminiert sich ja eh selbst) (geht aber nicht, weil der Dämon-Sohn nicht an den Browser des Client kommt). Ich könnte auch den Vater die Meldung an den Browser ausgeben lassen, einen Dämon-Sohn zeugen lassen (klingt schon ordinär...), der den REst abarbeitet und der Vater läßt sich durch den Apachen killen (weil er STDOUT zumacht), nachdem er die Statusmeldung abgegeben hat.
Stimmt. Eine Weiterleitung der Daten des frühreren Childs wäre nur über IPC
(Inter Process Communication) möglich; nämlich dann, wenn der Parent die Daten wieder
an STDOUT sendet und das gilt es ja zu verhindern...Geht aber auch nicht, weil der Dämon-Sohn trotzdem Ergebnisse an den Browser abgeben muß, und dort nicht hinkommt). Der Vater kann diese Meldungen aber via Pipe auch nicht mehr annehmen (wäre die einzige Verbindungsmöglichkeit), weil er nicht mehr exisiert.
Genau.
Wenn der Dämon-Sohn sich jetzt irgendwie festfrißt kann es sein, daß er sich selbst nicht mehr killen kann, und eine übergeordenete Instanz gibt es auch nicht mehr (Vater ist ja schon weg), außer den Administrator meines Providers. Er wäre ein Zombie. Also kann es kein Dämon sein.
Nicht ganz, ein Zombie ist ein bereits toter Prozess, deiner würde ja noch laufen, wenn
er sich selber nicht schliessen kann, aber naja, die Analogie stimmt schon :-)Bleibt nur ein normaler Parallelprozess bei dem der VAter als Kontrollinstanz vom Sohn bestehen bleibt und informiert wird, wenn der Sohn terminiert (also kein Dämon), der sohn wird aber ebenfalls gekillt, wenn der VAter vom Apachen umgelegt wird (wenn er
"wenn der Vater vom Apachen umgelegt wird", you made my day! - Halleluja, mein Sohn ward
vom Apachen umgenietet, diese höllischen Flugmaschinen a.k.a Hellikopter... Ürgs! ;-)Mein Problem ist, daß der Provider die Server-Pufferung nicht abschaltet (kann oder will). Hier liegt scheinbar die Lösungsmöglichkeit (weil eine ungepufferte Ausgabe, wie ich sie will, bei anderen Providern lauft). Im Moment verfolge ich deshalb zwei Möglichkeiten: einen eigenen kleinen http-server zu schreiben (der die Ausgabe ungepuffert über einen eigenen Port leitet), oder die Übertragunsgpakete mit unnützen Daten zu füllen (damit der Puffer geleert werden muß).
Naja, sind leider beides nur Workarounds, aber mir fällt leider auch nix gescheiteres
ein (was heisst hier eigentlich leider, es ist nunmal wirklich nicht Sinn des HTTP) :-(Viele Grüsse
Philipp
--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.-
Halihallo Philipp,
Bleibt nur ein normaler Parallelprozess bei dem der VAter als Kontrollinstanz vom Sohn bestehen bleibt und informiert wird, wenn der Sohn terminiert (also kein Dämon), der sohn wird aber ebenfalls gekillt, wenn der VAter vom Apachen umgelegt wird (wenn er
"wenn der Vater vom Apachen umgelegt wird", you made my day! - Halleluja, mein Sohn ward
vom Apachen umgenietet, diese höllischen Flugmaschinen a.k.a Hellikopter... Ürgs! ;-)Klingt martialisch, dabei bin ich ein BW-Drückeberger! Ich dachte bei Apache eigentlich auch mehr an den Indianer ;-) (/me war Karl-May-Fan)
Naja, sind leider beides nur Workarounds, aber mir fällt leider auch nix gescheiteres
ein (was heisst hier eigentlich leider, es ist nunmal wirklich nicht Sinn des HTTP) :-(Ich habe eine Lösung gefunden: ein erstes Perl macht erste Berinigungsarbeiten und schreibt eine HTML-Datei, die ich brauche (für die Anzeige "Nicht auflegen, wir suchen...") mit einer meta-Weiterleitung (Wartezeit=1 Sekunde) auf das 2. Perlprogramm (unterstützt mit einem Hilfslink, wenn der MEta bei alten Browsern nicht lauft). 2. Perlprogramm kontrolliert als erstes die Herkunft des aufrufenden Programms und weist alle fremden Hosts wieder ab (ist damit gegen die meisten DOS-Attacken und fremde Anfragen gewappnet). Effekt: Wenn jemand auf "Suchen" klicket, poppt ein neues Fenster auf, mit dem ersten Teil der Ergebnismaske und dem Hinweis "Wir suchen" sowie einer animierten Sanduhr-Gif (vielleicht auch mit einem Spruch a la www.suchen.com) und bis ein User das alles geschnallt hat (also nach 10-12 Sekunden) ist auch das eigentliche (2.) Perlprogramm soweit und schreibt den ersten Teil des Bildschirmes eben nochmal und danach das Suchergebnis. Gut, ne? *stolz-bin*
Gruß
Martin
-
-
-
-
-
Moin!
Verstehe ich nicht, bei mir ist der letzte BEfehl, der abgearbeitet wird, das schließen der STDOUT. Danach ist Sense...
Das lässt sich _konfigurieren_, wie so ziemlich alles andere auf der Welt...
Das wuerde mich mal interessieren. Wie konfiguriert man das beim Apache, weisst Du das?
So long
--
Manche Menschen haben einen Gesichtskreis vom Radius Null und nennen ihn ihren Standpunkt.
-- David Hilbert-
Halihallo Roland
Verstehe ich nicht, bei mir ist der letzte BEfehl, der abgearbeitet wird, das schließen der STDOUT. Danach ist Sense...
Das lässt sich _konfigurieren_, wie so ziemlich alles andere auf der Welt...
Das wuerde mich mal interessieren. Wie konfiguriert man das beim Apache, weisst Du das?shame on me! - Nein.
Ich war schlicht davon überzeugt, dass man dies Konfigurieren kann, da der Apache darin
sehr flexibel ist[1]; leider habe ich bisher meine Aussage nicht verifizieren können.[1] Was für eine Argumentation, ich weiss. Normalerweise weise ich auf "Nichtwissen" hin.
Viele Grüsse
Philipp
--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.
-
-
-
-
-
-
-
-
Hallo!
Herzlichen Dank an alle und speziell an Philipp, dessen Lösung die Ausgabe STDOUT zu schliessen, genau den Punkt traf. Jetzt ärgert es mich, daß ich nicht schon vor ein paar Monaten gefragt habe :-)
Viele Grüße
Harald