Hilfe Diskussion:Suche/insource

Beispiele für insource mit regex

Erst einmal ein Dankeschön an den Ersteller der Vorderseite. Als ein mögliches weiteres Beispiel so auf die Schnelle würde ich ja vorschlagen: "in den letzten zwei Jahren" insource:/[^(hatte)] in den letzten zwei Jahren [^(seines|seiner|ihres|ihrer|vor|bis|der|des)]/ Hilft die vorgeschobene Voltextsuche die Performanz zu verbessern? Es soll nach der relativen Zeitangabe in den letzten zwei Jahren gesucht werden. Treffer mit einleitendem hatte und folgendem ihres, ihrer, seines, seiner, vor, bis, der oder des sollen ausgeschlossen werden, da sie auf einen fixen Zeitbezug deuten. Ist mein regex noch fehlerhaft? Beispielsweise wird Thomas Schopf nicht gefunden, wohl aber von "in den letzten zwei Jahren" insource:/[^(hatte)] in den letzten zwei Jahren [^ihres|ihrer|vor|bis|der|des)]/ obwohl dort kein seines oder seiner folgt. Näher habe ich mir die gefundenen und die ausgeschlossenen Seiten noch nicht angeschaut. Mag ja sein, es sei nur eine Unzulänglichkeit der Datenbank oder der Suchfunktion. Eine Zeitüberschreitung kann es wohl nicht sein. Frohes Neues --Diwas (Diskussion) 21:09, 2. Jan. 2017 (CET)

• Bitte, gern geschehen.
• Ja, das Beispiel ist geeignet.
• Die vorangestellte Beschränkung kann in der Tat helfen, wenn die eigentliche komplexe Suche einen mit Zeitlimit rausschmeißt; so schlimm, dass man das nun bei jeder einmaligen Aktion von vornherein einbauen müsste, ist es nun auch wieder nicht.
• Der Suchbaum ist manchmal etwas verdorrt und bei komplexen Fragen nicht aktuell. Zuweilen hilft ein Purge auf eine Seite, die zuviel ist; es kann aber auch einige Wochen dauern, bis der Baum einen vergessenen Zweig durch Neuaufbau der gesamten Struktur wieder abwirft.
• In deinem Fall liegt es nicht an der Formulierung des RegExp, sondern daran, dass die momentan aktive Software nicht das macht, was in der Doku steht. Ich meine, das ging mal so, kann aber ein bis zwei Jahre her sein. Ich hatte jetzt nicht jedes Detail erneut durchgetestet.
  • Zurzeit wird der Inhalt der eckigen Klammern ganz normal behandelt, und die runden Klammern werden als solche ignoriert; und damit steht bei „seines“ ein n drin und das wurde von nicht getroffen.
• Das heißt, dass du einen nachgeschalteten gesonderten Filterausdruck -insource:/hatte in den … (seines|seiner|ihres|ihrer|vor|bis|der|des)/ benötigst.
• Wenn du es einbaust, empfehle ich zwei aufeinanderfolgende Beispiele; zunächst nur den RegExp mit allen Erläuterungen, in einem weiteren mit Vorschaltung und Bezug auf das vorangehende und Erläuterung nur dazu.

LG --PerfektesChaos 10:12, 3. Jan. 2017 (CET)

Sehr beschränkt

Die Regex-Suche ist ja sehr beschränkt. Weder allgemeine Ziffern \d noch Zeilenumbrüche \r \n noch Wörter \w sind als Ausdruck möglich. 147.142.139.221 11:14, 25. Jun. 2017 (CEST)

Ist das Leerzeichen ein Einzelzeichen?

Umseitig lese ich aktuell „Der Punkt . steht für jedes beliebige Einzelzeichen.“, es scheint aber so zu sein, dass das nicht für Leerzeichen gilt. -- Peter Gröbner -- 11:22, 6. Sep. 2019 (CEST)

Das muss eine Täuschung sein; ich arbeite seit Jahren mit den Ausdrücken, und das hätte mir schon oft auffallen müssen. Es gibt auch keinerlei syntaktische Begründung für deine Mutmaßung. VG --PerfektesChaos 14:31, 6. Sep. 2019 (CEST)

Danke für Deine Antwort. Dann war es ein anderer Fehler. Gruß, Peter Gröbner -- 15:08, 6. Sep. 2019 (CEST)

Syntax

Im Abschnitt Syntax ist per EN-Anmerkung zu lesen "Eine dritte Variante, die exakte Zeichenketten in " einschließt, wurde aus Performance-Gründen deaktiviert." Meines Erachtens funktioniert diese dritte Variante, und ist als Ergänzung zu regulär ausgedrückten Suchargumenten sogar sinnvoll und um einiges performanter. Gruß --Invisigoth67 (Disk.) 09:28, 16. Jan. 2020 (CET)

• Das hatte zumindest gestimmt, als ich dies vor Jahren am damaligen Ort geschrieben hatte.
• Kann schon sein, dass es zwischenzeitlich mal reaktiviert wurde, ohne dass ich etwas davon mitbekommen hätte.
• Wie genau die syntaktischen Auswirkungen sind, wäre erstmal zu erforschen.
  • Sinnvoll wäre, ein literally 1:1-match der Teilzeichenkette einzufordern.
  • Der normale Basis-Ausdruck wirkt auf ganze Wörter und ignoriert Groß- und Kleinschreibung.
  • Brauche ich mindestens das Wochenende, um das zu verifizieren, habe ein Dutzend Akut-Baustellen offen.
• Natürlich ist ein zeichen- oder wortgenaues direktes Suchen ohne RegExp-Auswertung performanter.
• Aber die letzten Jahre gab es halt nur Wort-Suche oder RegExp-Suche.

VG --PerfektesChaos 16:16, 16. Jan. 2020 (CET)

Seit ich vor Monaten hier gelesen habe, dass Regex-Suchen nach Möglichkeit mit einer Wort(gruppen)suche unter Anführungszeichen kombiniert werden sollen, mache ich das, was einerseits den Vorteil hat, dass es um einiges performanter ist, und zudem sind die Ergebnisse dann auch vollständiger (da reine Regex-Suchen häufig abbrechen und man dann nur ein Teilergebnis hat). Deshalb dachte ich auch, dass es nicht schaden kann, umseitig darauf hinzuweisen, weil es für den Suche-Benutzer hilfreich sein kann und gleichzeitig die Hamster entlastet. Viele Grüße --Invisigoth67 (Disk.) 07:33, 17. Jan. 2020 (CET)

Ich habe mir das mittlerweile intensiver angeguckt.

Es ist kein Vergleich zu einem RegExp.

• RegExp fordert Übereinstimmung auch in Groß- und Kleinschreibung und lässt auch Teilstücke aus Wörtern zu; selbst wenn keinerlei spezielle RegExp-Syntax verwendet würde, sondern nur Buchstaben.
• insource: ohne irgendwelche begrenzende Zeichen findet ein ganzes Wort, unabhängig von Groß- und Kleinschreibung, möglicherweise mit kleinen grammatikalischen Veränderungen (deutsch).
  • Nennen deren Programmierer „indexbasiert“.
• insource: mit ", der Gegenstand deiner Anfrage, findet aneinandergereihte ganze Wörter, unabhängig von Groß- und Kleinschreibung.

Es gibt aber noch weitere Gesichtspunkte, nämlich was an nicht-wortbildenden Zeichen zwischen den Wörtern stehen darf oder nicht, oder wie sich Auslassungen verhalten, was ich noch nicht restlos durchschaut habe.

Der einfachste, effizienteste oder vorgefilterte Ausdruck sollte verwendet werden, also möglichst nicht über zwei Millionen Artikel nach RegExp durchsuchen. Vorfilter wären auch linksto: hastemplate: usw.

Es gibt aber Fälle, wo keine ganzen Wörter oder andere Bedingungen möglich sind. Dann geht es nicht anders.

Umseitig steht ja auch: „Durch vorangestellte andere einschränkende Cirrus-Bedingungen, die effizienter ausgewertet werden können, sollten die zu durchsuchenden Seiten reduziert werden, um keine Zeitüberschreitung auszulösen.“

VG --PerfektesChaos 13:37, 2. Feb. 2020 (CET)

Time out bei komplexen Suchen

Seit gestern wird ein Teil der Suchen bis zum Time out der Wikimedia durchgezogen.

Error
Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.
See the error message at the bottom of this page for more information
Error: 504, Connection Timed Out

Es erfolgt kein Abbruch vorher und keine Ausgabe einer (Teil)-liste der Suchergebnisse.

Gruß --RonMeier (Diskussion) 14:34, 23. Jan. 2020 (CET)

Ja, wurde bereits verschiedentlich berichtet.

Es passiert erst seit wenigen Tagen und ist hoffentlich in einer Woche wieder weg.

Bis dahin möglichst schlaue Suchausdrücke verwenden; also so, dass sie nicht vor vollständigem Ergebnissatz abbrechen, indem schon mal grob vorgefiltert wird.

LG --PerfektesChaos 14:53, 23. Jan. 2020 (CET)

Fehlverhalten

Ich glaube, ich habe einen Bug gefunden: Die Suche nach (beide Varianten)

insource:/Ortsteil            	[ 	]*= Krumbach/
insource:/Ortsteil            	[ 	]{0,}= Krumbach/

(12 mal Leerzeichen, ein Tab, dann Leerzeichen und Tab in eckiger Klammer) findet den Artikel Krumbach (Lichtenau) nicht. Das Sternchen findet hier kein einmaliges Vorkommen. Das korrekte Ergebnis kommt, wenn ich das Sternchen weglasse, also explizit einmaliges Vorkommen fordere; außerdem mit + oder {1,}. Außerdem, wenn ich den Tab aus der Klammer rausnehme. Merkwürdigerweise auch, wenn ich statt dem = einen Punkt schreibe. Und noch merkwürdigerer Weise, wenn nach dem = ein * steht

insource:/Ortsteil            	[ 	]+= Krumbach/
insource:/Ortsteil            	[ 	]= Krumbach/
insource:/Ortsteil            	[ abcdef]*= Krumbach/
insource:/Ortsteil            	[ 	]*. Krumbach/
insource:/Ortsteil            	[ 	]*=* Krumbach/

Hat jemand eine Idee, was der Server da tut? --androl ☖☗ 20:52, 27. Feb. 2020 (CET)

Es kann auch daran liegen, dass dieser eine Artikel mal unvollkommen in den Suchbaum aufgenommen wurde.

In der fraglichen Artikelversion steht der Tab als vorvorletztes Zeichen nach 12 Leerzeichen, danach Tabulator, dann Leerzeichen und dann Gleichheitszeichen.

Die Syntax der Suchausdrücke kommt nicht von uns, sondern hier läuft komplett eine Fremdsoftware.

Möglicherweise gibt es noch eine undokumentierte Sonderbedeutung des Gleichheitszeichens; elastic.co.

Was funktioniert und Tab-sicher ist: insource:/Ortsteil[ ]*= *Krumbach/ (in der Klammer: Leerzeichen+Tab)

Was nach einigem Rumprobieren die Auswertung durcheinanderbringt, ist die Mischung von Leerzeichen davor und dann die Tab-einfangende Klammer mit auch Leerzeichen drin.

Eigentlich wird Whitespace einheitlich behandelt; aber offenbar nur im Wort-zerlegten Suchbaum und nicht bei RegExp.

Was uns lernt: Tabulatoren im Wikitext sind Mist und bringen alles durcheinander.

LG --PerfektesChaos 12:09, 28. Feb. 2020 (CET)

korrekte Abfrage, aber falsches Ergebnis

Hallo Suchexperten, ich möchte gern im Quelltext nach Abschnittverlinkungsfehlern suchen und z.B. folgenden Ausdruck ganz exakt finden: "Liste der meistverkauften Sachbücher in Deutschland#2001 ff|" dazu habe ich den Suchausdruck: insource: "Liste der meistverkauften Sachbücher in Deutschland\#2001 ff\|" genommen. Ich bekomme aber immer auch die Seiten angezeigt, die nach dem ff einen Punkt aufweisen und nicht danach sofort ein | enthalten. Wo liegt da der Fehler? Danke und Grüße --Mike Krüger, ?! 07:34, 19. Okt. 2021 (CEST)

Hallo Mike Krüger, durch die Pipe funktioniert die normale Textsuche nicht korrekt, also müsste hier noch zusätzlich mit einem regulären Ausdruck gesucht werden. Damit sollte es klappen, das Ergebnis ist aber ohnehin, dass es keinen Treffer gibt, wo die Pipe auf ff folgt. Gruß --Invisigoth67 (Disk.) 07:44, 19. Okt. 2021 (CEST)

Vielen Dank für die rasche Antwort, ich hatte jetzt schon händisch die …ff ohne folgenden Punkt korrigiert, daher kommt kein Ergebnis mehr. Grüße --Mike Krüger, ?! 17:26, 19. Okt. 2021 (CEST)