nicht angemeldet
(ZU DIESEM FORUM) (ARCHIV) Neue Suchfunktion: Freigabe zum Anwendertest
Hallo Archivbenutzer (also alle Leser ;-),
die "neue" Version des Archiv-Suchskripts ist gerade auf dem Server freigeschaltet worden.
Für eine Übergangsphase wird es wohl beide Skripts nebeneinander geben; insbesondere sind noch keine Links umgestellt, die zeigen also noch auf das alte Skript.
Das neue findet man unter </cgi-local/sfasuch2.pl>.
Ein HTML-Frontend gibt es nicht mehr - das Skript erkennt, daß es ohne Parameter aufgerufen wurde und gibt dann nur das Formular aus.
Was ist anders als vorher?
a) mehrere Terme (getrennt durch Leerzeichen) werden automatisch mit AND verknüpft
b) Strings in "..." dürfen Leerzeichen enthalten
c) beginnt ein Term mit +, dann muß er enthalten sein
d) beginnt ein Term mit -, dann darf er nicht enthalten sein
e) beginnt *kein* Term mit +, dann wird automatisch vor jedem Term ohne - ein + ergänzt
f) regular expressions gehen noch, sind aber über ein Auswahlfeld abschaltbar
g) case-Sensitivität ist über ein Auswahlfeld abschaltbar (Achtung: Bei meinen Messungen machte das viel aus, case-sensitive Suche kann 2-3 mal schneller sein!)
h) die Trefferzahl ist limitierbar
i) die Treffer werden numeriert angezeigt
j) die Suchdauer wird ausgegeben
Viel Spaß beim Suchen!
Michael Schröpl
-
Hi Michael,
vielen Dank für die Mühe!!
Ich befürchte nur, dass die Anzahl der Threads hier abnehmen wird ;-))
Gruesse, Martin
-
Hallo Michael!
Ich bedanke mich auch herzlich für die Suchfunktion! Das Erstemal das ich erlebt habe, daß ein Flame was genützt hat *g*. Wie war das "Initiativstrafe"?
Auf jedenfall nochmals danke!
CU Roman
-
Hallo Martin
Ich befürchte nur, dass die Anzahl der Threads hier abnehmen wird ;-))
Ich würde mich freuen, wenn die Quantitaet des alltaeglichen, gegen 14 Uhr seinen Hoehepunkt erreichenden hektischen "uaaa-das-funktioniert-nicht"-Gelabers mal ein wenig abnehmen wuerde, und wenn stattdessen die Qualitaet, die zweifellos da ist, hier staerker zum Tragen kommt. Eine optimierte Suche ist wirklich ein gutes Argument, um "auf-die-Schnelle-Frager" erst mal auf Entdeckungsreise im Archiv zu schicken.
viele Gruesse und ein dickes Danke an Michael (und auch Frank)
Stefan Muenz-
Guten Morgen, Stefan
Ich würde mich freuen, wenn die Quantitaet des alltaeglichen, gegen 14 Uhr seinen Hoehepunkt erreichenden hektischen "uaaa-das-funktioniert-nicht"-Gelabers mal ein wenig abnehmen wuerde, und wenn stattdessen die Qualitaet, die zweifellos da ist, hier staerker zum Tragen kommt. Eine optimierte Suche ist wirklich ein gutes Argument, um "auf-die-Schnelle-Frager" erst mal auf Entdeckungsreise im Archiv zu schicken.
Das Blöde ist ja, d a s s man viele Besucher hier erst 'mal daruaf hinweisen muss - war allerdings bei mir auch nicht anders, schäm'.
Ach ja, für die "2-Frames-auf-einmal-Ändern"-Frage könnte man ja einen direkten Archiv-Link in der Titelleiste installieren ;-))
Verschlafene Gruesse,
Martin
-
-
Ich befürchte nur, dass die Anzahl der Threads hier abnehmen wird ;-))
Das erste, was hoffentlich passieren wird, ist, daß diejenigen, die sich an ein entsprechendes Archiv-Posting erinnern und tatsächlich für *andere* danach suchen, *damit* nun wenigstens etwas weniger Arbeit haben!
Das alleine wäre mir die Implementierung wert gewesen.Aber ich selbst habe jetzt auch das Gefühl, daß sich Suchen mehr lohnt als früher - das Preis-/Leistungs-Verhältnis für den Sucher ist jedenfalls besser geworden.
Und ich habe durchaus wieder etwas bei diesem Projekt gelernt (vor allem durch Frank Schönmanns Unterstützung in Sachen regular expressions) ... das ist ja auch was wert.
Wenn ich also das Angenehme mit dem Nützlichen verbinden konnte, dann ist das fein! :-)
So, und jetzt warte ich erst einmal auf gefundene bugs und weitere Verbesserungswünsche ... :-)
-
-
Hallo Michael,
super, scheint alles zu funktionieren!!!
Aber die Einstellung von Beachtung der Groß-/Kleinschreibung, würde ich standardmäßig ausschalten!Alles Gute,
Reiner-
super, scheint alles zu funktionieren!!!
Fein :-)
Aber die Einstellung von Beachtung der Groß-/Kleinschreibung, würde ich standardmäßig ausschalten!
Wenn Perl "Rusch" mit einem beliebigen String case-sensitiv vergleichen muß, dann ist genau ein match fällig - schlimmstenfalls fünf Zeichenvergleich in Folge.
Bei Case-insensitivem Vergleich muß Perl theoretisch 2 hoch (Länge (Rusch)) Vergleiche machen.
Das wird natürlich intern optimiert: Durch schrittweisen Vergleich sind es wenig mehr als doppelt so viele Vergleiche - aber das wiederum behindert den lookahead ...Will sagen: case-insensitive Suche ist *signifikant* langsamer und belastet den Server um Faktor 2-3 mehr.
Deshalb habe ich das defaultmäßig abgeschaltet - die "gedankenlose" Suche soll erst mal sase-sensitiv ablaufen, das produziert immerhin auch ein paar Treffer. :-)Wer case-sensitiv suchen *muß*, dem mute ich einen zusätzlichen Mausklick zu ...
Außerdem: Eine case-insensitive Suche nach "[Rr]usch" mit regular expressions ist rasend schnell - fast so schnell wie die nach "Rusch" ...
-
-
Hallo Michael,
das Script ist ja wirklich sehr schön flott und brachte in kürzester Zeit 456 Treffer.... Na ja, ich hatte nach PHP gesucht ...
nichts ist so alt wie der Tip von gestern, deshalb schlage ich vor, daß die frischesten Treffer zuoberst stehen, im Moment ist das Datum aufsteigend dargestellt, der älteste Treffer zuerst, kann man das umstellen?
das denke ich, käme uns allen sehr entgegen, denk mal daran, daß das Forum noch 5 Jahre besteht und dann sucht jemand nach "2 Frames gleichzeitig...." und bekommt Tips von anno-browser-tobak ;-)
Gruß
Connie-
deshalb schlage ich vor, daß die frischesten Treffer zuoberst stehen, im Moment ist das Datum aufsteigend dargestellt, der älteste Treffer zuerst, kann man das umstellen?
Bisher macht die Trefferausgabe:
for ($i = 0; $i < $max_hits; $i++)
{
... (ausgeben)
}
, und man könnte die Laufrichtung der Schleife einfach umdrehen. Kein Problem also.Die spannendere Frage ist: Können sich die Benutzer auf eine mehrheitlich gewünschte Richtung einigen, oder muß wieder ein Schalter mehr im Formular her? (Auch das sind nur 10 Zeilen zu kopieren, aber das Formular würde halt immer länger und abschreckender ... ;-)
Halt - gerade fällt mir ein, daß meine Aussage von oben nur "vorerst" gilt.
Denn: Wenn Frank Schönmann wirklich ein Rating der Treffer einbauen will, dann hat das natürlich Vorrang bei der Treffersortierung.
Ha - ganz einfach: Wir bauen das Alter des Postings in die Rating-Funktion mit ein! (Frank, liest Du mit? Die Rating-Funktion wird wohl doch eher evolutionär entstehen müssen ...)
-
-
Hallo Michael
Folgendes ist mir noch eingefallen, was zu implementieren vielleicht nicht dumm waere (ich stelle es einfach mal zur Diskussion hiermit - ach, macht das Spass, mal "Verbesserungsvorschlaege" machen zu duerfen <g>):
1. die "intelligente" Variantensuche fuer Umlaute und scharfes s. Also dass er sowohl Münzen also auch Muenzen findet <g> bzw. eine Checkbox hat, wo man diese Variantensuche ein-/ausstellen kann.
2. die ausdrueckliche Suche nach Sprachbefehlen. In der Suchindexdatei stehen im Nachrichtentext beispielsweise Dinge wie:
<frame name=verweise src=verweise.htm>
Waere doch schoen, wenn der User jetzt einfach im Suchfeld <frame> oder <frame src=> eingeben kann, und so etwas wuerde gefunden!
Zwar kann man diese Dinge auch mit regulaeren Ausdruecken loesen, aber die sind nun mal bekanntlich nicht jedermanns Sache.3. Da die Formulardaten ja nicht so umfangreich sind, koennte man sie nicht auch mit GET auswerten? Der Vorteil waere, dass dann bei der Suchtrefferausgabe das Zustandekommen des Ergebnisses in der URL-Zeile stehen wuerde. Dies koennte man wiederum rauskopieren und hier im Forum als "langen Link" bei der Beantwortung von Fragen anbieten. Denn manchmal reicht die einfache Form wie /cgi-local/sfasuch.pl?ASP einfach nicht.
viele Gruesse
Stefan Muenz-
hi!
Folgendes ist mir noch eingefallen, was zu implementieren vielleicht nicht dumm waere (ich
stelle es einfach mal zur Diskussion hiermit - ach, macht das Spass, mal
"Verbesserungsvorschlaege" machen zu duerfen <g>):Hast du dir auch verdient... ;)
- die "intelligente" Variantensuche fuer Umlaute und scharfes s. Also dass er sowohl
Münzen also auch Muenzen findet <g> bzw. eine Checkbox hat, wo man diese
Variantensuche ein-/ausstellen kann.
Hm, das stelle ich mir nicht so schwierig vor. Da mit regulären Ausdrücken gesucht wird, kann man ja Alternativen in den Suchstring einbauen. Man müsste halt nur für alle Möglichkeiten diese Alternativen im Skript angeben, aber der Aufwand dürfte sich in Grenzen halten.
Dazu vielleicht ein Suchtip, der IMHO noch nicht erwähnt wurde: hat man einen Suchbegriff, der an nur einer oder zwei Stelle case-insensitiv sein soll, sollte man den Suchbegriff zb. so eingeben: "[Ww]ort" statt gleich die entsprechende Option zu aktivieren, da die Suche dadurch in unseren Versuchen enorm beschleunigt wurde.
- die ausdrueckliche Suche nach Sprachbefehlen. In der Suchindexdatei stehen im
Nachrichtentext beispielsweise Dinge wie: <frame name=verweise src=verweise.htm>
Waere doch schoen, wenn der User jetzt einfach im Suchfeld <frame> oder <frame src=>
eingeben kann, und so etwas wuerde gefunden!
Hm, das stelle ich mir schon etwas komplizierter vor. Vielleicht sollte man das ganz hinten auf die TODO-Liste setzen ;)
- Da die Formulardaten ja nicht so umfangreich sind, koennte man sie nicht auch mit GET
auswerten? Der Vorteil waere, dass dann bei der Suchtrefferausgabe das Zustandekommen
des Ergebnisses in der URL-Zeile stehen wuerde. Dies koennte man wiederum rauskopieren
und hier im Forum als "langen Link" bei der Beantwortung von Fragen anbieten. Denn
manchmal reicht die einfache Form wie /cgi-local/sfasuch.pl?ASP einfach nicht.
Zur Zeit wird durch die Methode überprüft, ob ein richtiges Formular oder nur ein Suchbegriff übergeben wurde. Man müsste dann halt ein paar zusätzliche Überprüfungen in die Parameter-Funktion einbauen. Im Grunde kein Problem...
Was mir aber noch aufgefallen ist: anscheinend gibt es unter ganz bestimmten Umständen (Suchbegriffe mit und ohne Anführungszeichen, gemischt und viele hintereinander), die aber sehr selten auftreten dürfen, Probleme mit dem Parsen des Suchstrings :( Ich schaue nachher mal, was sich da machen lässt, habe schon eine Idee, wie man das wahrscheinlich umgehen kann.
bye, Frank!
- die "intelligente" Variantensuche fuer Umlaute und scharfes s. Also dass er sowohl
-
Hallo Michael und Danke!!!!!
»» Hallo Stefan Muenz !!!
Hallo Forumer- Da die Formulardaten ja nicht so umfangreich sind, koennte man sie nicht auch mit GET auswerten? Der Vorteil waere, dass dann bei der Suchtrefferausgabe das Zustandekommen des Ergebnisses in der URL-Zeile stehen wuerde......
Ein weiterer Vorteil wäre, daß beim NN je nach Sicherheitseinstllung nicht immer diese Warung (Daten werden ungeschützt übermittetl....) erscheinen würde.
Gruß Wilm
-
ach, macht das Spass, mal "Verbesserungsvorschlaege" machen zu duerfen <g>):
Das hast Du Dir verdient!
Dieses Skript war nämlich ganz nebenbei ein ernsthafter Test dafür, wie sehr Du bereit bist, "loszulassen" und SELFAKTUELL zu dem kooperativen Internet-Technologie-Portal werden zu lassen, das in http://www.teamone.de/selfaktuell/version.htm angedacht ist ...- die "intelligente" Variantensuche fuer Umlaute und scharfes s. Also dass er sowohl Münzen also auch Muenzen findet <g> bzw. eine Checkbox hat, wo man diese Variantensuche ein-/ausstellen kann.
Kein Problem, wenn genau definiert ist, was wie zu ersetzen ist. Es sollte nicht schwerer sein als das "escapen" der regular-expression-Metazeichen (und *das* war für Frank ein Einzeiler ;-).
Ein Beispiel alleine reicht mir aber nicht aus. Okay: ü -> (üue) kriege ich hin. Was noch alles?
(Auch ue -> (üue), beispielsweise?)In jedem Falle wäre die Änderung weitgehend isoliert im Tokenizer-Komplex, und es wären dort auch nur ein paar zusätzliche s/.../-Zeilen und die Abfrage eines zusätzlichen Formular-Flags. Also: machbar.
- die ausdrueckliche Suche nach Sprachbefehlen. In der Suchindexdatei stehen im Nachrichtentext beispielsweise Dinge wie:
<frame name=verweise src=verweise.htm>
Waere doch schoen, wenn der User jetzt einfach im Suchfeld <frame> oder <frame src=> eingeben kann, und so etwas wuerde gefunden!
Hm. da muß ich jetzt raten, was genau Du meinst. Insbesondere das abschließende ">" von "<frame>" paßt da natürlich nicht ins Konzept.
Ansonsten: Nach "frame" kann man ja bereits suchen.
Nach "<frame" auch - leider gibt das dann Null Treffer. Warum? Weil die Codierung des "<"-Zeichens zwischen Posting-Skript und Such-Skript unterschiedlich zu sein scheint. Was genau schreibt denn das Posting-Skript ins Archiv?
Ich vermute, es reicht schon aus, das "<"-Zeichen genau wie die Umlaute in der Sucheingabe nach HTML zu konvertieren - das wäre eine Kleinigkeit
(eine Zeile mehr pro umzusetzendes Zeichen).Das ist letztlich das umgekehrte Problem dazu, daß ich bei "Schröpl" im Archiv weiterhin null Treffer habe. Denn das Such-Skript codiert das "ö" nach HTML um - das Posting-Skript offenbar nicht ... hier müssen sich beide an dieselben Spielregeln halten. (Und außerdem müßte man mal schnell mit Perl über den Archiv-Index drüberfahren, um diesen ebenfalls "gleichzuschalten".)
Also? Das Problem ist nicht isoliert lösbar ...- Da die Formulardaten ja nicht so umfangreich sind, koennte man sie nicht auch mit GET auswerten? Der Vorteil waere, dass dann bei der Suchtrefferausgabe das Zustandekommen des Ergebnisses in der URL-Zeile stehen wuerde. Dies koennte man wiederum rauskopieren und hier im Forum als "langen Link" bei der Beantwortung von Fragen anbieten. Denn manchmal reicht die einfache Form wie /cgi-local/sfasuch.pl?ASP einfach nicht.
Hm, das ist HTML, da kenne ich mich nicht so aus. ;-)
Ganz ehrlich: Deine Eingabeschnittstelle für das Suchskript habe ich mit ganz spitzen Fingern angefaßt, weil ich nicht einschätzen konnte, welche verborgenen Abhängigkeiten (zu Datenbeständen des Forums etc.) damit verbunden sind. Die "Integration des Gesamtkunstwerkes" kann außer Dir derzeit niemand machen.Der von Cheatah immer wieder gepostete Zweizeiler für die Analyse der CGI-Parameter würde das Skript möglicherweise um 30 Zeilen verkürzen.
Das kann man aber jederzeit problemlos nachrüsten, weil es mit der Logik der Sucherei ja nun überhaupt nichts zu tun hat ... je modularer das Skript ist, desto leichter kann man lokale Änderungen mit geringem Risiko einbauen.-
Hallo Michael
Dieses Skript war nämlich ganz nebenbei ein ernsthafter Test dafür, wie sehr Du bereit bist, "loszulassen" und SELFAKTUELL zu dem kooperativen Internet-Technologie-Portal werden zu lassen, das in http://www.teamone.de/selfaktuell/version.htm angedacht ist ...
Auweia, da hab ich aber Glueck gehabt <g>.
Auch wenn "Loslassen" nicht gerade meine Paradedisziplin ist, bin ich eigentlich sehr dankbar, wenn mir Leute hier auch mal Arbeit abnehmen. Ich bin halt nur immer etwas vorsichtig, weil es haeufig von Geltungsdrang zerfressene Windbeutel sind, die mir ihre Dienste anbieten. Da bin ich mir bei Leuten wie dir oder Frank natuerlich sicher, dass ich auf der richtigen Seite bin.Ein Beispiel alleine reicht mir aber nicht aus. Okay: ü -> (üue) kriege ich hin. Was noch alles?
(Auch ue -> (üue), beispielsweise?)eigentlich nur die Umlaute und scharfes S:
Eingabe "ae" sollte sowohl "ae" als auch "ä" finden wenn gewuenscht (Checkbox)
"oe" -> "oe" und "ö"
"ue" -> "ue" und "ü"
"Ae" -> "Ae" und "Ä"
"Oe" -> "Oe" und "Ö"
"Ue" -> "Ue" und "Ü"
"ss" -> "ss" und "ß"
Umgekehrt ist problematisch und sollte weggelassen werden. Denn Eingabe "ä", die auch alle "ae" findet, macht meines Erachtens keinen Sinn, da "ae" auch was anderes als die Umschreibung eines Umlauts sein kann.Hm. da muß ich jetzt raten, was genau Du meinst. Insbesondere das abschließende ">" von "<frame>" paßt da natürlich nicht ins Konzept.
Eben. Es wird von der normalen Suche nicht gefunden - nur eine "mitdenkende" Suche koennte erkennen, dass der User das HTML-Tag meint. Die Suche muesste also gewissermassen selbstaendig den vom User eingegebenen Suchausdruck interpretieren und das Pattern-Matching intern anpassen. Ich denke jedenfalls, in dem inhaltlichen Kontext, in dem wir uns hier bewegen, darf man < und > im Suchausdruck als Wunsch nach Finden eines HTML-Tags interpretieren. Diese Art von "intelligentem" Anpassen des eigentlichen Pattern-Matchings in Bezug auf HTML sollte natuerlich ein-/ausschaltbar sein (Checkbox).
Dass ein erfahrener User all das auch durch regulaere Ausdruecke erschlagen kann, ist klar. Aber denkt immer dran, dass die Mehrzahl der User, die dieses Suchformular benutzen, eben keinen blassen Schimmer von RE haben.
Das ist letztlich das umgekehrte Problem dazu, daß ich bei "Schröpl" im Archiv weiterhin null Treffer habe. Denn das Such-Skript codiert das "ö" nach HTML um - das Posting-Skript offenbar nicht ... hier müssen sich beide an dieselben Spielregeln halten.
In der Suchindexdatei stehen Umlaute ganz normal drin - die Suchindexdatei ist also gewissermassen eine iso-8559-1-Datei. Nur die HTML-eigenen Zeichen < und > werden, wie schon oben erwaehnt, maskiert. Insofern sollte eine Suche nach ö auch Treffer mit ö bringen. Frank hat mich seinerzeit lange genervt deswegen, schliesslich hat er ja auch ein ö im Namen und wollte sich gern mal finden <g>.
Hm, das ist HTML, da kenne ich mich nicht so aus. ;-)
Einfach <form ... method="get">
Und fuer die Weiterverarbeitung in Perl siehe <selfhtml/tgbf.htm#a1>. So weit ich weiss, nutzt ihr die cgi.pm zjm Formularparsen. Ich weiss nicht, ob die beide Methoden unterstuetzt.viele Gruesse
Stefan Muenz-
Auch wenn "Loslassen" nicht gerade meine Paradedisziplin ist, bin ich eigentlich sehr dankbar, wenn mir Leute hier auch mal Arbeit abnehmen. Ich bin halt nur immer etwas vorsichtig, weil es haeufig von Geltungsdrang zerfressene Windbeutel sind, die mir ihre Dienste anbieten. Da bin ich mir bei Leuten wie dir oder Frank natuerlich sicher, dass ich auf der richtigen Seite bin.
:-) ... und die Crew für die Forum-Auslese darf in diesem Kontext auch mal wieder erwähnt werden http://www.teamone.de/selfaktuell/forumsauslese.htm#a3 ...
Hm. da muß ich jetzt raten, was genau Du meinst. Insbesondere das abschließende ">" von "<frame>" paßt da natürlich nicht ins Konzept.
Eben. Es wird von der normalen Suche nicht gefunden - nur eine "mitdenkende" Suche koennte erkennen, dass der User das HTML-Tag meint. Die Suche muesste also gewissermassen selbstaendig den vom User eingegebenen Suchausdruck interpretieren und das Pattern-Matching intern anpassen. Ich denke jedenfalls, in dem inhaltlichen Kontext, in dem wir uns hier bewegen, darf man < und > im Suchausdruck als Wunsch nach Finden eines HTML-Tags interpretieren. Diese Art von "intelligentem" Anpassen des eigentlichen Pattern-Matchings in Bezug auf HTML sollte natuerlich ein-/ausschaltbar sein (Checkbox).Und Du hältst diese Checkbox und den entsprechenden Erklärungstext wirklich für sinnvoll statt dem Benutzer zu erklären, er solle einfach nur nach "<table" suchen?
(Die Umcodierung von < und > ist bereits eingebaut - zwei Zeilen.)Und fuer die Weiterverarbeitung in Perl siehe <selfhtml/tgbf.htm#a1>. So weit ich weiss, nutzt ihr die cgi.pm zum Formularparsen. Ich weiss nicht, ob die beide Methoden unterstuetzt.
Noch nutze ich da gar nichts Anderes als Deinen Original-Text - aber "use CGI;" wäre in der Tat die Alternative, die mir vorschweben würde, falls sie (mindestens) dasselbe leistet wie Deine Routine. (Ausprobieren ... am Montag abend, vorher bin ich ausgebucht.)
-
-
-
Hallo Michael,
super die neue Suche.
Nur eine Sache: die regulaeren Ausdruecke.
Ich habe mal gelesen (noch nicht selber getestet), dass unguestig formulierte regulaere Ausdruecke auf einen langen Text angewendet, (und das ist das Archiv ja wohl) mitunter Stunden (Tage?) benoetigen um ausgewertet zu werden. Besteht da nicht die Gefahr, dass der Server zu stark belastet wird? Wenn dies zutrifft (hab's im Buch "Regulaere Ausdruecke" vom O'Reily-Verlag gelesen), waere es da nicht besser, keine RegExp zuzulassen?
Gruss
Manne-
Hallo Manne,
Ich habe mal gelesen (noch nicht selber getestet), dass unguestig formulierte regulaere Ausdruecke auf einen langen Text angewendet, (und das ist das Archiv ja wohl) mitunter Stunden (Tage?) benoetigen um ausgewertet zu werden.
Da es ein CGI-Script ist, gibt es wohl im schlimmsten Fall hoechstens einen CGI-Timeout. Der Browser wartet jedenfalls nicht mehrere Tage auf Antwort <g>. Was aus solchen faul gewordenen CGI-Prozessen auf der Betriebssystemebene des Servers wird, weiss ich freilich auch nicht. Vielleicht weiss es jemand?
viele Gruesse
Stefan Muenz-
Da es ein CGI-Script ist, gibt es wohl im schlimmsten Fall hoechstens einen CGI-Timeout. Der Browser wartet jedenfalls nicht mehrere Tage auf Antwort <g>. Was aus solchen faul gewordenen CGI-Prozessen auf der Betriebssystemebene des Servers wird, weiss ich freilich auch nicht. Vielleicht weiss es jemand?
Die werden nach dem TimeOut gekillt!
Wie hoch das eingestellt ist, hängt von Deinem Admin/Provider ab.Reiner
-
-
Besteht da nicht die Gefahr, dass der Server zu stark belastet wird? Wenn dies zutrifft (hab's im Buch "Regulaere Ausdruecke" vom O'Reily-Verlag gelesen), waere es da nicht besser, keine RegExp zuzulassen?
Ich habe die regular expressions nicht eingebaut (die funktionieren schon mit dem alten Skript - probier's mal aus!), sondern im Gegenteil den Schalter eingebaut, mit dem man sie abschalten kann (und sie sogar defaultmäßig abgeschaltet).
Ansonsten hast Du völlig recht.
Immerhin besteht jetzt die Hoffnung, daß niemand mehr *versehentlich* einen regular expression eingibt, weil er jetzt immerhin einen Mausklick mehr zum Einschalten braucht. ;-)
-
-
Hallo Michael!
Wenn ich nach
head -<head> -</head>
suche (nicht case-sensitiv), erscheinen trotzdem allerhand Beiträge, die die ausgeschlossenen Zeichenketten enthalten - auch, wenn ich diese in "..." setze.
Mache ich was falsch oder das Script?
Steffen
-
Wenn ich nach
head -<head> -</head>
suche (nicht case-sensitiv), erscheinen trotzdem allerhand Beiträge, die die ausgeschlossenen Zeichenketten enthalten - auch, wenn ich diese in "..." setze.Mache ich was falsch oder das Script?
Weder noch. ;-)
Wenn Du nach <head> suchst, bekommst Du konsequenterweise (..., 7.04 Sekunden später, ...) gar keinen Treffer.
Das liegt daran, daß das "<"-Zeichen vom Such-Skript (derzeit) unverändert durchgereicht wird, im Archiv aber als < zu stehen scheint. Umgekehrt steht das "ö" im Archiv als "ö", während das Such-Skript nach "ö" sucht.Hier fehlen einfach noch die gemeinsamen Spielregeln zwischen Datenbestand und Suchverfahren - sinnvollerweise sollten sich beide aufeinander zu bewegen (intern alles HTML-codieren, weil man dadurch ggf. weitere Meta-Zeichen für regular expressions frei bekommt), und das kann ich in dem Suchskript allein nicht tun (zumal ich das Posting-Skript "von innen" noch gar nicht kenne).
-
Hallo Michael
Hier fehlen einfach noch die gemeinsamen Spielregeln zwischen Datenbestand und Suchverfahren - sinnvollerweise sollten sich beide aufeinander zu bewegen
Alle HTML-Tags, die in Nachrichtentexten stehen, werden vor dem Schreiben in die Suchindexdatei in ihre Entities < und > umgewandelt. Die Suche koennte also die Zeichen < und > im Sucheingabefeld als Wunsch interpretieren, nach HTML-Tags zu suchen, und diese im eigentlichen zeilenweisen Pattern-Matching in die Entities umzuwandeln, so dass die entsprechenden Textstellen gefunden werden.
viele Gruesse
Stefan Muenz-
Alle HTML-Tags, die in Nachrichtentexten stehen, werden vor dem Schreiben in die Suchindexdatei in ihre Entities < und > umgewandelt. Die Suche koennte also die Zeichen < und > im Sucheingabefeld als Wunsch interpretieren, nach HTML-Tags zu suchen, und diese im eigentlichen zeilenweisen Pattern-Matching in die Entities umzuwandeln, so dass die entsprechenden Textstellen gefunden werden.
Hm ... hm ... hm ...
Wenn das stimmen würde, dann müßte man "<table" bereits jetzt suchen können, und zwar durch die Eingabe "<table". Man kann ja die "Übersetzung" nach HTML notfalls selbst machen, solange sie nicht ins Skript eingebaut ist.
Ausprobieren: Wir nehmen das wichtigste aller HTML-tags, nämlich die Suchzeichenkette "<g>" (notiert als "<g>").
Und erhalten 0 Treffer! Wieso denn das?!Ein Blick in die von Dir mitgelieferte Indexdatei produziert folgende überraschende Erkenntnis:
a) Das Posting-Skript scheint tatsächlich alle "<"-Zeichen umzucodieren.
b) Aber es scheint dabei alle ">"-Zeichen wegzuwerfen!
In dem mir vorliegenden Index sind jedenfalls alle Tags "hinten offen" ... und was im Archiv nicht gespeichert ist, kann auch nicht gefunden werden.Verifikation: "<g" als Suchzeichenkette liefert 1606 Treffer in 15.7 Sekunden. Was meine Beobachtung zu stützen scheint ...
Und nun? Ich wage gar nicht vorzuschlagen, den Schwanzabschneider zu reparieren und irgendwie das gesamte Archiv neu zu indexen ... :-(
-
Wenn das stimmen würde, dann müßte man "<table" bereits jetzt suchen können, und zwar durch die Eingabe "<table". Man kann ja die "Übersetzung" nach HTML notfalls selbst machen, solange sie nicht ins Skript eingebaut ist.
Sorry - irgendwie habe ich da um eine Meta-Ebene zu wenig excaped oder so. Ich meinte: Die HTML-Codierung aus <../../tcad.htm#a2> selbst auf die Eingabe des Suchformulars anwenden ...
-
-
-
Alles klar, außer:
intern alles HTML-codieren, weil man dadurch ggf. weitere Meta-Zeichen für regular expressions frei bekommt
Warum sollten denn Zeichen, die im Archiv stehen, nicht auch als Meta-Zeichen verwendbar sein? Wenn z.B. ">" ein Meta-Zeichen ist, muß der Suchausdruck "<head>" in Anführungszeichen stehen - egal, ob ">" als ">" im Archiv steht oder als ">". (Es sei denn, du willst den Besucher ernsthaft nach <head> suchen lassen!) Implementieren kann man doch beide Varianten, oder?
Steffen
-
Ooops!
So war das nicht gemeint. Nochmal:
Warum sollten denn Zeichen, die im Archiv stehen, nicht auch als Meta-Zeichen verwendbar sein? Wenn z.B. ">" ein Meta-Zeichen ist, muß der Suchausdruck "<head>" in Anführungszeichen stehen - egal, ob ">" als ">" im Archiv steht oder als "@gt;". (Es sei denn, du willst den Besucher ernsthaft nach @lt;head@gt; suchen lassen!) Implementieren kann man doch beide Varianten, oder?
Du weißt schon, was gemeint ist.
-
(Es sei denn, du willst den Besucher ernsthaft nach @lt;head@gt; suchen lassen!)
Nein, das will ich bestimmt nicht - das <-Zeichen umzucodieren habe ich bereits (lokal bei mir) nachgerüstet.
Implementieren kann man doch beide Varianten, oder?
Ich möchte gerne nur die "beste" Variante implementieren. Das Skript soll möglichst einfach verständlich bleiben.
Und meine Vorstellung der "besten" Variante ist: Alles, was irgendwie kritisch sein könnte (HTML-Sonderzeichen, Umlaute etc.) von allen drei beteiligten Programmen (Posting-Skript, Schwanzabschneider, Such-Skript) in der HTML-codierten Form verarbeiten lassen.
Ich muß Stefan allerdings offenbar noch überreden, da mitzuspielen ... Unterstützung dankend erbeten. ;-)
-
-
-
-