XPFilter V1.4 - Dokumentation Copyright (c) 1994-96 Robin Sommer 20. November 1996 - 1 - INHALT 1. EINFÜHRUNG .......................................................... 4 1.1 Was ist XPFilter ? .............................................. 4 1.2 Rechtliches ..................................................... 5 1.3 Copyrights und Warenzeichen ..................................... 5 1.4 Dank ............................................................ 6 2. DIE INSTALLATION .................................................... 6 2.1 Das Einbinden in CrossPoint ..................................... 7 3. GRUNDLAGEN UND EINFACHE MUSTER ...................................... 8 3.1 Die Muster ...................................................... 8 3.1.1 Aufbau einer Musterdatei ................................. 8 3.1.2 Aufbau eines einzelnen Musters .......................... 10 3.1.3 Suchbedingungen ......................................... 11 3.1.4 Grundlegende Aktionen ................................... 13 4. REFERENZ ........................................................... 15 4.1 Kennungen für Suchbedingungen .................................. 16 4.1.1 ZConnect-Kennungen ...................................... 16 4.1.1.1 ABS ............................................ 16 4.1.1.2 BET ............................................ 17 4.1.1.3 BEZ ............................................ 17 4.1.1.4 EMP ............................................ 17 4.1.1.5 LEN ............................................ 17 4.1.1.6 MID ............................................ 18 4.1.1.7 TYP ............................................ 18 4.1.1.8 X-XP-FTO ....................................... 18 4.1.2 Neue Kennungen .......................................... 18 4.1.2.1 BODY ........................................... 18 4.1.2.2 BODY-I ......................................... 19 4.1.2.3 GRUPPEN ........................................ 19 4.1.2.4 GRUPPEN-KOP .................................... 19 4.1.2.5 IN-ADRBUCH ..................................... 19 4.1.2.6 LAST-BEZ ....................................... 20 4.1.2.7 QUOTE-ANTEIL ................................... 20 4.1.2.8 QUOTE-ZEILEN ................................... 20 4.1.2.9 SUCHEN ......................................... 21 4.1.2.10 XBET ........................................... 21 4.2 Aktionen ....................................................... 21 4.2.1 ABBRUCH (Schalter) ...................................... 22 4.2.2 AMENDE (Schalter) ....................................... 22 4.2.3 ANHAENGEN (Schalter) .................................... 23 4.2.4 ARCHIV (Schalter) ....................................... 23 4.2.5 ATTRIBUT ................................................ 23 4.2.6 AUSGABE (Schalter) ...................................... 24 4.2.7 BATCH ................................................... 24 4.2.8 BEZIEHEN (Schalter) ..................................... 25 4.2.9 BINAER (Schalter) ....................................... 25 4.2.10 BRETT ................................................... 25 - 2 - 4.2.11 DEBUG ................................................... 25 4.2.12 DEL (Schalter) .......................................... 26 4.2.13 EINMAL (evtl. Schalter) ................................. 26 4.2.14 ERHALTEN (Schalter) ..................................... 27 4.2.15 EXPORT .................................................. 27 4.2.16 GRUND (Schalter) ........................................ 28 4.2.17 IMPORT .................................................. 29 4.2.18 INAKTIV ................................................. 29 4.2.19 LOESCHEN (evtl. Schalter) ............................... 29 4.2.20 LOWPRIO (Schalter) ...................................... 30 4.2.21 MARKIEREN (evtl. Schalter) .............................. 30 4.2.22 N-ANTWORT-AN ............................................ 32 4.2.23 N-DISKUSSION-IN (evtl. Schalter) ........................ 32 4.2.24 N-HEADER ................................................ 33 4.2.25 N-STICHWORT ............................................. 34 4.2.26 NAME .................................................... 35 4.2.27 ORIGINAL (Schalter) ..................................... 35 4.2.28 PHYS (Schalter) ......................................... 36 4.2.29 PUFFER (Schalter) ....................................... 36 4.2.30 REIMPORT (evtl. Schalter) ............................... 36 4.2.31 SENDEN .................................................. 37 4.2.32 SERVER ................................................. 38 4.2.33 STOP (Schalter) ......................................... 38 4.2.34 SWAP (evtl. Schalter) ................................... 39 4.2.35 TITEL ................................................... 39 4.2.36 TEXT .................................................... 40 4.2.37 VERSCHIEBEN (Schalter) .................................. 40 4.2.38 ZIEL .................................................... 40 4.3 Die SUCHEN-Kennung ............................................. 40 4.4 Der Aufruf ..................................................... 42 4.5 Konfigurationsdatei ............................................ 51 4.6 Die XPFILTER.DEF Datei ......................................... 52 4.7 Variablen ...................................................... 53 4.7.1 Grundlegendes ........................................... 54 4.7.2 Einfache Variablenzuweisung ............................. 55 4.7.3 Variablenzuweisung mit Regulären Ausdrücken ............. 56 4.7.4 Variablen und BATCH ..................................... 57 4.7.5 Probleme ................................................ 59 4.8 Einschränken von Suchbedingungen ............................... 60 4.8.1 Häufigkeiten ............................................ 60 4.8.2 Bereiche ................................................ 61 4.8.3 Kombinierte Häufigkeits-/Bereichsangaben ................ 62 5. DIVERSES ........................................................... 62 5.1 Allgemeine Tips ................................................ 63 5.2 Beispiele ...................................................... 65 5.2.1 Öffentliche Antworten finden ............................ 65 5.2.2 Themen suchen ........................................... 66 5.2.3 Bretter strukturieren ................................... 66 - 3 - 5.2.4 Automatische Antworten .................................. 67 5.2.5 PGP-Schlüssel einlesen .................................. 68 5.2.6 FAQs sammeln ............................................ 68 5.2.7 Einschränken von Crosspostings .......................... 70 5.2.8 Mailinglisten ........................................... 71 6. DAS ZCONNECT-FORMAT ................................................ 72 7. REGULÄRE AUSRDÜCKE ................................................. 73 8. ERRORLEVEL ........................................................ 76 - 4 - 1. EINFÜHRUNG 1.1 Was ist XPFilter ? Bei XPFilter handelt es sich um einen Filter für EMail, der speziell auf das Programm CrossPoint von Peter Mandrella abgestimmt ist. Es soll dazu dienen, die täglich steigende Nachrichtenflut strukturieren zu helfen. Wichtige Nachrichten können in spezielle Bretter geleitet werden, unwichtige werden einfach gelöscht. Tägliche Routineaufgaben können über Batchdateien erledigt werden, Nachrichten können automatisch weitergeleitet werden, einfache Mailserver sind machbar und vieles andere mehr. Mein Ziel bei XPFilter war von Beginn an eine größtmögliche Flexibilität. Um die zu erreichen, werden sogenannte "Muster" benutzt. In diesen läßt sich mit Hilfe von "Vollständigen Regulären Ausdrücken" genau festlegen, wie Nachrichten auszusehen haben, damit die gewünschten Aktionen ausgeführt werden. Wenn das Prinzip der Muster erst einmal durchschaut ist, läßt sich XPFilter - wie mir inzwischen von vielen Seiten bestätigt worden ist - auf einfache Weise so einrichten, daß die persönlichen Anforderungen erfüllt werden. XPFilter ist speziell auf das Nachrichtenformat "ZConnect" (->S.72) ausgelegt. Dieses wird von CrossPoint fast ausschließlich benutzt: bis auf das *alte* Z-Netz Format Z3.8 werden alle anderen Nachrichtenstandards nach ZConnect gewandelt. Daher funktioniert XPFilter in allen Netzen, die von CrossPoint unterstützt werden mit Ausnahme eben jener Z3.8 Nachrichten. Da Z3.8 aber wohl in - hoffentlich - naher Zukunft praktisch keine Rolle mehr spielen wird, ist dies wohl kein großer Nachteil ... In dieser Dokumentation folgt nach Hinweisen zur Installation eine Einführung in den Aufbau der Muster. In dem Teil werden jedoch nur ein paar grundlegende Dinge erklärt. Eine Gesamtübersicht findet sich in dem darauf folgenden Kapitel REFERENZ. Dieses sollte - auch wenn nur ein geringer Teil daraus wirklich benutzt wird - *komplett* durchgelesen werden, da es einige wichtige Informationen enthält. Das anschließende Kapitel gibt ein paar allgemeine Hinweise. Danach folgen einige Beispielmuster, die sich mit nur kleinen Anpassungen verwenden lassen sollten. Das Kapitel über die Regulären Ausdrücke sollte ebenfalls auf alle Fälle gelesen werden - auch wenn sie vom Prinzip her bereits bekannt sind - da in XPFilter einige Erweiterungen und Besonderheiten existieren. Man sollte bitte nicht aufgrund des Umfangs dieser Dokumentation - 5 - erschrecken. Ich weiß selber, daß sie für einen Eingangsfilter sehr groß geraten ist, aber ich glaube, daß eine ausführliche Beschreibung allen Beteiligten (also auch mir :-) im Endeffekt mehr hilft, als eine Anleitung, in der die Hälfte fehlt. Als Nachteil macht die Ausführlichkeit natürlich erstmal wesentlich mehr Arbeit, die sich aber bestimmt später auszahlt. XPFilter ist einfacher einzurichten, als es auf den ersten Blick aussehen mag! 1.2 Rechtliches Ich gebe keinerlei Garantie für eine Fehlerfreiheit von XPFilter. Sollte es irgendeinen Schaden an Hard- oder Software anrichten, zu Datenverlust führen oder den Wellensittich sterben lassen, so übernehme ich keinerlei Verantwortung dafür. Die Benutzung von XPFilter geschieht grundsätzlich auf eigene Gefahr. XPFilter ist Freeware, es darf für private Zwecke kostenlos benutzt und kopiert werden. Allerdings bleiben alle Rechte beim Autor. Jegliche Änderung an Programm oder Dokumentation ist nicht gestattet. Ebenso ist die kommerzielle Nutzung oder Verbreitung nicht erlaubt. Da ich sehr interessiert daran bin, zu erfahren, wie weit sich XPFilter verbreitet, wäre es nett, wenn mir jeder Nutzer eine kurze Nachricht schicken würde. Ebenso sind Vorschläge, Kritik und insbesondere Fehlermeldungen jederzeit willkommen. Adressiert werden können alle Nachrichten an | robin@shire.owl.de | | Außerdem bin ich auch Präsenten aller Art nicht abgeneigt :-) : | | Robin Sommer | Reinherstr. 10 | 33100 Paderborn | Germany | | Konto-Nr.: 29108586 | BLZ : 472 501 01 (Sparkasse Paderborn) 1.3 Copyrights und Warenzeichen o (c) 1994-96 für XPFilter und die Dokumentation bei Robin Sommer - 6 - o ZCONNECT ist ein eingetragenes Warenzeichen der ZERBERUS GmbH. o ZERBERUS ist ein eingetragenes Warenzeichen der ZERBERUS GmbH. o UNIX ist ein eingetragenes Warenzeichen der AT&T Inc. und USL Inc. o Fido und FidoNet sind eingetragene Warenzeichen von Tom Jennings und Fido Software. 1.4 Dank Natürlich darf ein Dank an all diejenigen nicht fehlen, die zur Entstehung und Erweiterung von XPFilter beigetragen haben. Mein Dank geht an o alle Betatester, die als erstes ihre Puffer den neuen Versionen anvertraut haben und mit ihren Anregungen und Tests eine große Hilfe gewesen sind o all diejenigen, die mir im Laufe der XPFilter-Entwicklung - trotz Freeware-Status - kleine, die Motivation fördernde Spenden und Präsente haben zukommen lassen o Stefan P. Wolf für seinen XP-Companion (siehe beiliegende XPFilter-FAQ) o alle diejenigen, die die vielen Ideen für die Dinge hatten, die jetzt in XPFilter implementiert sind; insbesondere an Marc Aurel für seine MARKIEREN-Idee | o die netten Menschen, die in den diversen Crosspoint-Newsgroups | unermüdlich auch zu XPFilter Hilfe leisten o Tatu Ylonen, der seine Implementierung der Regulären Ausdrücke als Public Domain freigab (siehe FAQ) o Thomas Wagner für seine Public-Domain-Funktion "EXEC mit Speicherauslagerung" (siehe FAQ) o und natürlich an Peter Mandrella für sein hervorragendes CrossPoint 2. DIE INSTALLATION Die Installation teilt sich im Wesentlichen in zwei Teile. Einmal muß die CrossPoint-Konfiguration so angepaßt werden, daß XPFilter nach jedem Netzanruf gestartet wird. Der zweite Teil ist das Erstellen einer persönlichen Musterdatei. - 7 - Während Ersteres hier im Anschluß beschrieben wird, befaßt sich mit den Mustern das nächste Kaptitel. 2.1 Das Einbinden in CrossPoint CrossPoint zu "überreden", XPFilter nach jedem Netzanruf zu starten, ist relativ einfach, da es bereits eine Schnittstelle für derartige Filter anbietet. Als erstes sollten alle XPFilter beiliegenden Dateien in ein Verzeichnis kopiert werden. Am unproblematischsten ist es, dafür das Verzeichnis zu nehmen, in dem sich auch CrossPoint befindet. Anschließend muß XPFilter für jede Box eingetragen werden, für die es benutzt werden soll. Dazu muß unter dem CrossPoint-Menüpunkt "Edit/Boxen/Edit/Diverses" im Feld "Eingangsfilter" der Aufruf stehen. Die formale Aufrufsyntax für XPFilter lautet dort: XPFILTER [Optionen] -u$PUFFER [ Musterdatei1 [Musterdatei2 [...] ] ] Wenn XPFilter im selben Verzeichnis wie CrossPoint steht, reicht es für den Anfang bei "Eingangsfilter" folgendes einzutragen: XPFILTER -n -u$PUFFER Für muß der Name der Datei eingetragen werden, in der sich die Muster (->S.8) befinden. $PUFFER wird von CrossPoint automatisch durch den Namen des beim Netzanruf empfangenen Puffers ersetzt. Die Option -n bewirkt, daß die Konfigurationsdatei XPFILTER.CFG eingelesen wird (->S.51). Sollte sich CrossPoint allerdings in einem anderen Verzeichnis befinden, so versucht XPFilter zuerst, es mittels der PATH-Umgebungsvariable zu lokalisieren. Falls dies fehlschlägt - spätestens erkennbar an einer Fehlermeldung :-) - so muß XPFilter das Verzeichnis explizit mitgeteilt werden. Das kann über die Aufrufoption -r (->S.48) oder über eine Konfigurationsdatei (->S.51) geschehen. Eine dritte Möglichkeit ist das Setzen der Umgebungsvariable XPDIR, indem z.B. in der AUTOEXEC.BAT-Datei eine Zeile SET XPDIR= eingefügt wird. muß dabei durch den Namen des Verzeichnisses ersetzt werden, in dem sich CrossPoint befindet. - 8 - Wichtig ist, daß alle Dateinamen und Pfadangaben innerhalb von XPFilter - mit Ausnahme der Konfigurationsdatei (->S.51) sowie der Datei XPFILTER.DEF (->S.52) - standardmäßig (->S.43) als relativ zum CrossPoint-Verzeichnis betrachtet werden. Befindet sich die gewünschte Datei an einer anderen Stelle, so sollte der komplette Pfad angegeben werden. 3. GRUNDLAGEN UND EINFACHE MUSTER Nach der Installation in CrossPoint kommt der wichtigste Teil: Die Erstellung der Muster. In diesem Kapitel soll zunächst eine Einführung gegeben werden, ohne bis ins letzte Detail zu gehen. Es werden hier nur die wichtigsten Möglichkeiten beschrieben, ein Großteil der leistungsfähigen, aber nicht zwingend benötigten Funktionen sind hier ausgelassen. Sie finden sich zusammen mit einigem anderen im Referenz- Kapitel (->S.15). 3.1 Die Muster Ein Muster gibt an, wie eine Nachricht aussehen muß, damit bestimmte Aktionen ausgeführt werden. Zu diesen Aktionen gehört bspw. das Kopieren oder Löschen von Nachrichten. Wenn XPFilter einen Puffer filtert, geht es alle Muster der Reihe nach durch. Es wird jeweils verglichen, ob die Nachricht so aussieht, wie es das Muster angibt. Wenn eine Nachricht als passend befunden worden ist, werden die ebenfalls im Muster angegebenen Aktionen ausgeführt. 3.1.1 Aufbau einer Musterdatei Eine Musterdatei ist eine normale Textdatei, die mit jedem Texteditor erstellt werden kann. Sie enthält die einzelnen Muster, die XPFilter sagen, was es zu tun hat. Ein Muster ist ein Block von Textzeilen. Beendet wird dieser Block mit einer Zeile "END". Nach dieser Zeile beginnt automatisch das nächste Muster. Innerhalb einer Musterdatei werden alle Zeilen, die mit einem Semikolon oder einer Raute ('#') beginnen ebensowenig beachtet wie Leerzeilen. Schematisch dargestellt kann eine Musterdatei z.B. folgenden Aufbau haben: - 9 - END # Dies ist eine Kommentarzeile END Man sollte übrigends eine Musterdatei nach jedem Ändern einmal mit Hilfe der Aufrufoption -c (->S.44) überprüfen lassen, um nicht erst beim Netzanruf festzustellen, daß ein Fehler vorhanden ist. Falls eine Musterzeile zu lang wird (und sei es nur "der Optik wegen" :-), kann sie umbrochen werden. Dazu ist es lediglich nötig, an das Ende der Zeile ein oder mehrere Leerzeichen gefolgt von einem '\' zu schreiben. Diese Umbruchmarkierung wird von XPFilter dann intern entfernt und stattdessen der Inhalt der nächsten Zeile angehängt. Dabei werden allerdings alle führenden Leerzeichen der angehängten Zeile nicht beachtet. Ein Beispiel für eine umbrochene Zeile, um das ganze etwas deutlicher zu machen: irgendein wer weiß wie langer text \ hier geht es weiter Wenn XPFilter dieses einliest, interpretiert es das genauso als wenn folgende Zeile im Muster gestanden hätte: irgendein wer weiß wie langer texthier geht es weiter *Achtung*: Es wird wirklich exakt auf diese Art interpretiert, d.h. zwischen den Wörtern "text" und "hier" erscheint kein Leerzeichen, da sowohl am Ende der ersten Zeile als auch am Anfang der zweiten alle Leerzeichen (genauer: Whitespaces) überlesen werden. Auf diese Weise lassen sich beliebig viele "echte" Zeilen zu einer "logischen" Zeile verbinden. Innerhalb eines solchen Umbruchs können auch Kommentar- oder Leerzeilen eingefügt werden. So würde irgendein wer weiß wie langer text \ ; Dies ist ein Kommentar hier geht es weiter - 10 - ebenfalls so interpretiert, wo oben beschrieben. 3.1.2 Aufbau eines einzelnen Musters Ein Muster hat zwei Hauptbestandteile. Einer sind die "Suchbedingungen" (->S.11), die genau angeben, auf welche Nachrichten dieses Muster passen soll. Der andere Teil sind die "Aktionen" (->S.13). Sie dienen dazu, XPFilter mitzuteilen, was mit all den Nachrichten, auf die dieses Muster zutrifft, geschehen soll. Der grundsätzliche Aufbau einer Zeile innerhalb eines Musters ist jedoch immer gleich. Jede Zeile beginnt mit einer sogenannten "Kennung". Das ist im Prinzip einfach ein Name, der bestimmt, wie der Rest der Zeile zu interpretieren ist. Dabei gibt es zwei Typen von Kennungen. Einmal sogenannte "Schalter". Sie stehen alleine in der Zeile, ihnen folgt nichts mehr. Z.B. ist "LOESCHEN" (->S.29) so ein Schalter, dessen Funktion darin besteht, Nachrichten zu löschen (wie der Name schon sagt :). Die zugehörige Zeile würde also einfach so aussehen: LOESCHEN Der andere Typ Kennung benötigt noch weitere Angaben. Es handelt sich hierbei um eine Art Zuweisung. Wieder beginnt die Zeile mit der Kennung, darauf kommt ein '='-Zeichen und anschließend folgt der sogenannte "Inhalt". Ein Beispiel: die Kennung BRETT (->S.25) benötigt als Inhalt den Namen des CrossPoint-Brettes, in das Nachrichten kopiert werden sollen. Eine Zeile des Muster könnte also lauten: BRETT=/Meine Post Leerzeichen vor und nach dem '=', sowie am Ende der Zeile werden nicht beachtet. Die Reihenfolge der Zeilen innerhalb eines Musters ist beliebig und hat keinerlei Auswirkungen auf die Bearbeitung. Auch die Groß-/Kleinschreibung aller Kennungen sowie fast aller Inhalte ist beliebig. Beendet wird ein Muster - wie schon gesagt - mit einer Zeile "END". - 11 - 3.1.3 Suchbedingungen Mit den Suchbedingungen ist es möglich, das Aussehen von Nachrichten zu beschreiben. Sie orientieren sich dabei zum großen Teil am ZConnect-Format. Das ist das Format, in dem die Nachrichten vorliegen, wenn XPFilter sie zu Gesicht bekommt. Darin sind neben dem eigentlichen Nachrichtentext alle relevanten Steuerdaten wie Absender, Empfänger, Betreff u.ä. vermerkt. Sollte der Aufbau einer Nachricht in diesem Format nicht bekannt sein, empfiehlt sich ein Blick in das entsprechende Kapitel (->S.72). Eine Suchbedingung beginnt - wie alle Zeilen eines Musters - mit einer Kennung. Der Name der Kennung entspricht in den meisten Fällen direkt der zugehörigen ZConnect-Headerzeile, z.B. BET für den Betreff, EMP für den Empfänger und ABS für den Absender. Der Inhalt, der der Kennung zugewiesen wird, ist ein Text, der in allen Nachrichten in dieser Headerzeile gesucht wird. Beispiel: BET=XPFilter Dies ist eine vollständige Suchbedingung, die XPFilter anweist, die Betreffe aller Nachrichten nach dem Text "XPFilter" zu durchsuchen. Wenn in einer Nachricht "XPFilter" im Betreff gefunden wird, trifft diese Bedingung zu. Von diesen Suchbedingungen lassen sich innerhalb eines Musters beliebig viele kombinieren. Es kann auch mehrmals dieselbe Kennung benutzt werden. Angenommen, in einem Muster sind folgende Suchbedingungen vorhanden: BET=XPFilter EMP=/FIDO/CROSSPOINT.GER ABS=Hans Mustermann Es wird nun bei jeder Nachricht jede Suchbedingung getestet. Das ganze Muster trifft für eine Nachricht zu, wenn bei ihr alle Suchbedingungen *gleichzeitig* erfüllt sind. Eine passende Nachricht müßte in diesem Beispiel also im Betreff "XPFilter" haben, der Empfänger müßte "/FIDO/CROSSPOINT.GER" lauten und der Absender müßte "Hans Mustermann" enthalten. Wenn alle Bedingungen zutreffen, werden die gewünschten Aktionen (->S.13) ausgeführt. - 12 - Wichtig ist, daß der zu suchende Text nicht exakt dem Inhalt der zugehörigen Headerzeile entsprechen muß. Es genügt, wenn er *irgendwo* innerhalb der Zeile vorhanden ist. Eine Bedingung wie BET=ilt würde daher auch auf einen Nachrichtenbetreff wie "XPFilter" zutreffen. Desweiteren ist die Groß-/Kleinschreibung - bis auf eine Ausnahme bei der Kennung BODY (->S.18) - beliebig. Die Schreibweise hat keinen Einfluß auf das Zutreffen einer Bedingung. Es gibt auch die Möglichkeit, XPFilter mitzuteilen, daß eine Nachricht *nur eine* der Suchbedingungen erfüllen muß, um als passend befunden zu werden. Dazu muß lediglich der Schalter ODER mit ins Muster aufgenommen werden. Obiges Beispiel würde damit lauten: BET=XPFilter EMP=/FIDO/CROSSPOINT.GER ABS=Hans Mustermann ODER Wieder wird für jede Nachricht jede Suchbedingung getestet. Das ganze Muster trifft aber bereits dann auf eine Nachricht zu, wenn *irgendeine* der Suchbedingungen erfüllt ist. Es müßte also eine Nachricht sein, die im Betreff "XPFilter" hat, *oder* der Empfänger müßte "/FIDO/CROSSPOINT.GER" lauten, *oder* der Absender müßte "Hans Mustermann" enthalten. (*Hinweis*: Die obigen Beispiele sind alle noch keine vollständigen Muster. Es sind wie gesagt nur die Suchbedingungen, denen noch die Aktionen (->S.13) hinzugefügt werden müssen.) Etwas ungenau war die Aussage von eben, der Inhalt einer Suchbedingung sei der zu suchende Text. Dies ist nur bedingt richtig. In Wahrheit stellt der Inhalt einen "Vollständigen Regulären Ausdruck" dar. Dies ist eine - hauptsächlich von UNIX her bekannte - Möglichkeit, zu suchende Texte auf sehr flexible Art anzugeben. Eine genauere Beschreibung der Syntax und der Möglichkeiten befindet sich im Kapitel "Reguläre Ausdrücke" (->S.73). Desweiteren lassen sich innerhalb der Suchbedingungen noch einschränkende Bereiche und Häufigkeitsangaben einfügen. Auch dazu später mehr (->S.61). An dieser Stelle sind hauptsächlich zwei Dinge wichtig zu wissen: Auch ein "normaler" zu suchender Text (in obigen Beispielen jeweils "XPFilter") stellt bereits einen Regulären Ausdruck dar, der nichts weiter tut, als *exakt* diese Zeichenfolge zu suchen - was für viele Anwendungen schon reichen kann. - 13 - Allerdings gibt es paar Zeichen, die innerhalb Regulärer Ausdrücke eine besondere Funktion haben. Es handelt sich dabei um sogen. "Steuerzeichen" (->S.73); z.B. ist der Punkt ('.') ein solches. Um nach einem Steuerzeichen selber zu suchen - d.h. ohne die Funktion, die es innerhalb Regulärer Ausdrücke ausübt, zu verwenden - muß diese Sonderbehandlung ausgeschaltet werden. Dazu wird einfach das Zeichen '\' davorgesetzt. Ein konkretes Beispiel: Soll im Betreff der Text "Die Sonne scheint." gesucht werden, so lautet die zugehörige Suchbedingung: BET=die sonne scheint\. *Tip*: Wenn mal ein Muster nicht so funktioniert, wie es geplant war, sollte man mal alle Suchbedingungen abklopfen, ob nicht irgendwo ungewollt ein Steuerzeichen benutzt worden ist. Eine Liste aller Steuerzeichen befindet sich ebenfalls im Kapitel "Reguläre Ausdrücke". Eines der Steuerzeichen für Reguläre Ausdrücke möchte ich auch an dieser Stelle erwähnen. Wenn der zu suchende Text mit dem Zeichen '~' *beginnt*, wird der Wahrheitsgehalt der Bedingung umgedreht, d.h. die Bedingung paßt auf alle Headerzeilen, die den entsprechenden Text *nicht* enthalten. Damit läßt sich z.B. testen, ob es sich bei einer Nachricht um eine öffentliche handelt: EMP=~@ Wenn es sich bei einer Nachricht um eine persönliche handelt, kommt in ihrer Empfängerzeile *garantiert* ein '@'-Zeichen vor. Diese Bedingung trifft auf alle Nachrichten zu, die kein '@' im Empfänger haben und damit auf alle öffentlichen Nachrichten. Neben den Suchkennungen, die den ZConnect-Headerzeilen entsprechen, gibt es weitere, die kein passendes Äquivalent haben, wie z.B. BODY-I (->S.19), um auch den Nachrichtentext durchsuchen zu können. Eine nähere Beschreibung der wichtigsten ZConnect-Kennungen sowie aller von XPFilter zusätzlichen zur Verfügung gestellten findet sich im Referenzkapitel (->S.15). Desweiteren existiert auch eine Möglichkeit, nicht in XPFilter integrierte Suchkennungen selber zu definieren. Auch dazu später mehr (->S.52). 3.1.4 Grundlegende Aktionen Nachdem wir nun die Suchbedingungen angeben und XPFilter damit sagen - 14 - können, wie Nachrichten auszusehen haben, kommt der zweite wichtige Teil eines Musters: die Aktionen. XPFilter kann, wenn es einmal befunden hat, daß eine Nachricht genau den Suchbedingungen entspricht, viele verschiedene Dinge mit ihr anstellen. Die einfachste und meistbenutzte Aktion ist wohl das schlichte Kopieren einer Nachricht in ein beliebiges Brett. Das bedeutet, daß die Nachricht beim späteren Lesen in CrossPoint sowohl in den Originalbrettern auftaucht, als auch dort, wo sie hinkopiert wurde. Um eine Nachricht zu kopieren ist es lediglich nötig, XPFilter das Zielbrett mitzuteilen. Dafür gibt es die Kennung BRETT (->S.25) : BRETT=/Filter/CrossPoint BODY-I=CrossPoint|XP END Dies ist bereits ein vollständiges Muster, das alle Nachrichten, die entweder "CrossPoint" oder "XP" im Text enthalten, in das Brett "/Filter/CrossPoint" kopiert (Anmerkung: Das '|' ist eines der vielen Steuerzeichen innerhalb der Regulären Ausdrücke und steht für ein "oder"; näheres dazu steht - wie schon gesagt - im Kapitel "Reguläre Ausdrücke" (->S.73)). XPFilter erreicht das Kopieren dadurch, daß der Nachricht einfach ein neuer Empfänger hinzugefügt wird, der dem Brettnamen entspricht. Allerdings hat dieses Vorgehen zwei Besonderheiten: o Die Bretter, die mit der BRETT-Kennung angegeben sind, werden von CrossPoint nicht automatisch angelegt. Stattdessen werden alle Empfänger einer Nachricht, die nicht in der Brettliste vorhanden sind, einfach überlesen. Daher müssen diese Bretter entweder per Hand oder mit Hilfe der Aufrufoption -i (->S.46) angelegt werden. *Achtung*: Falls man dieses nicht macht, scheint es später so, als würde XPFilter die Nachrichten weder finden noch bearbeiten. Dadurch entsteht leicht Verwirrung, da man - je nach persönlicher Einstellung - entweder an seinen Mustern oder an XPFilter zweifelt ... :-) o Dadurch, daß eine Nachricht nach dem Kopieren mehr Empfänger hat als das Original, "weiß" CrossPoint von alleine nicht mehr, wohin eine evtl. öffentliche Antwort zu schicken ist. | Daher fügt XPFilter den kopierten Nachrichten DISKUSSION-IN-Headerzeilen | | | - 15 - | | | | hinzu, die CrossPoint in die Lage versetzen, eine Antwort nur in die | ursprünglichen Bretter zu senden. Wichtig ist allerdings zu wissen, daß | dieses erst mit neueren CrossPoint-Versionen reibungslos funktioniert, | da ältere bei Nachrichten mit mehr als einem originalem Empfänger nicht | in der Lage waren, alle DISKUSSION-IN-Zeilen wie gewünscht auszuwerten. Andere Möglichkeiten, das automatische Setzen von DISKUSSION-INs zu beeinflussen, bieten die Kennungen N-DISKUSSION-IN (->S.32) sowie die Aufrufoption -f (->S.45). Ganz oder teilweise umgehen läßt es sich mit den Kennungen PHYS (->S.36) und BEZIEHEN (->S.25). Die zweite häufig benutzte Aktion ist das Verschieben. Sie wird aktiviert, indem in das Muster zusätzlich zu der BRETT-Angabe noch der Schalter VERSCHIEBEN eingefügt wird: BRETT=/Filter/CrossPoint VERSCHIEBEN BODY-I=CrossPoint|XP END Alle Nachrichten, die vorher kopiert wurden, werden nun in das Brett verschoben, was bedeutet, daß XPFilter alle Originalempfänger entfernt und anschließend den neuen Empfänger einfügt. Um genau zu sein werden die alten Empfänger standardmäßig nicht entfernt, sondern in KOP-Zeilen gewandelt (->S.50). Dadurch ist innerhalb von CrossPoint an den Kopieempfängern immer noch erkennbar, woher die verschobenen Nachrichten ursprünglich stammen. Die dritte grundlegende Aktion ist das Löschen. Damit lassen sich z.B. endlose Diskussionen einfach aus dem Puffer entfernen. Die zugehörige Kennung für diese Aktion heißt LOESCHEN (wie sonst? :) LOESCHEN EMP=~@ BODY-I=Yellow Point END Damit werden alle öffentlichen Nachrichten (->S.13), in deren Body der Text "Yellow Point" vorkommt, unwiederbringlich gelöscht. 4. REFERENZ Das vorherige Kapitel sollte eine Einführung geben und das grundsätzliche Prinzip der Muster verdeutlichen. In der Hoffnung, daß dies einigermaßen gelungen ist, werde ich in diesem Kapitel nun eine Gesamtübersicht der Möglichkeiten geben, die XPFilter noch beherrscht und die weit über das - 16 - einfache Kopieren/Verschieben/Löschen hinausgehen. Allerdings werden darunter viele Dinge sein, die die meisten Benutzer gar nicht benötigen werden. Ich selber benutze auch nur einen kleinen Auschnitt des Ganzen im praktischen Einsatz. Die vielen Funktionen sind nicht in XPFilter integriert, um die Übersichtlichkeit zu verschlechtern, sondern um die zu Beginn angesprochene Flexibilität zu gewährleisten. :-) Beispiele für Muster sowie einige allgemeine Tips finden sich im nächsten Kapitel. 4.1 Kennungen für Suchbedingungen In diesem Teil findet sich zuerst eine Beschreibung der Kennungen, die von Namen und Bedeutung her zu denen der entsprechenden ZConnect-Headerzeilen identisch sind. Anschließend folgen die von XPFilter zusätzlich zur Verfügung gestellten, die kein passendes ZConnect-Äquivalent haben. 4.1.1 ZConnect-Kennungen Die folgenden Kennungen stellen die wichtigsten ZConnect-Kennungen dar. Neben diesen kennt XPFilter standardmäßig auch die seltener für eine Suchbedingung benötigten Kennungen ANTWORT-AN, DISKUSSION-IN, EB, EDA, FILE, LDA, MAILER, OAB, OEM, ORG, POST, ROT, SPERRFRIST, STAT, STICHWORT, TELEFON, WAB, ZUSAMMENFASSUNG, X-XP_F. Zusätzlich lassen sich beliebige andere Kennungen benutzen, wenn sie zuvor mit Hilfe der XPFILTER.DEF-Datei (->S.52) definiert worden sind. Eine vollständige Erläuterung aller offiziellen ZConnect-Kennungen findet sich in der Dokumentation des Standards, die sich ohnehin zu lesen lohnt. Sie ist z.B. in der CrossPoint-Supportbox zu bekommen. 4.1.1.1 ABS In einer Nachricht steht in dieser Headerzeile die vollständige Adresse des Absenders. Nach der Adresse kann noch ein Realname angegeben sein. Dieser wird durch ein Leerzeichen abgetrennt und steht in Klammern. Ein Beispiel für eine Absenderangabe in einer Nachricht: robin@shire.owl.de (Robin Sommer) - 17 - 4.1.1.2 BET Der Betreff der Nachricht. 4.1.1.3 BEZ Diese Headerzeile dient in einer Nachricht der Bezugsverkettung, wie sie in CrossPoint z.B. für den Kommentarbaum benutzt wird. Der Inhalt stellt die Message-ID (->S.18) der Nachricht dar, auf die diese sich bezieht. Diese Kennung ist innerhalb einer Nachricht optional. 4.1.1.4 EMP Steht für den Empfänger der Nachricht. Dies ist entweder der Name eines Brettes oder die Adresse eines Users. Bei letzterem ist garantiert ein '@'-Zeichen vorhanden, so daß sich damit zwischen öffentlichen und privaten Nachrichten unterscheiden läßt. Die Zeile muß mind. einmal in einem Nachrichtenheader enthalten sein. Hat eine Nachricht mehrere EMP-Zeilen, handelt es sich um ein sogen. "Crossposting". 4.1.1.5 LEN In einer Nachricht enthält die LEN-Zeile die Länge der Nachricht in Bytes. Hierbei gibt es eine Besonderheit bei den Suchbedingungen in XPFilter. Da es bei einer Längenangabe selten sinnvoll ist, auf Gleichheit bzw. Ungleichheit zu testen, kann bei LEN auch auf "kleiner als" und "größer als" getestet werden. Für ersteres könnte eine Suchbedingung im Muster z.B. so aussehen: LEN=<1024 Diese Bedingung paßt auf alle Nachrichten, deren Länge kleiner als 1024 Bytes ist. LEN=>1024 paßt auf alle mit einer Länge größer als 1024 Bytes. Anstatt Bytes lassen sich bei der Vergleichszahl auch KByte angeben, indem ein 'k' an die Zahl angefügt wird. Das erste Beispiel würde dann z.B. lauten LEN=>1k - 18 - Diese Syntax gilt nur für die "normalen" Suchbedingungen, etwas anders - wenn auch ähnlich - verhält es ich bei der SUCHEN-Kennung (->S.40). Bitte beachten: Auch wenn die Schreibweise anderes nahelegen mag, vergleichen diese Bedinungen wirklich auf "größer als" bzw. "kleiner als", *nicht* auf "größer oder gleich" bzw. "kleiner oder gleich". 4.1.1.6 MID Steht für die Message-ID einer Nachricht. Dies ist eine eindeutige Kennung, an der sich diese Nachricht jederzeit identifizieren läßt. Mit Hilfe dieser ID werden z.B. Bezüge mit BEZ (->S.17) hergestellt. 4.1.1.7 TYP Wenn diese Headerzeile in einer Nachricht nicht vorhanden ist, handelt es sich um eine Textnachricht. Ansonsten kennzeichnet der Inhalt den Typ der Nachricht. Binärnachrichten haben i.d.R. "BIN" als Inhalt. 4.1.1.8 X-XP-FTO Diese Kennung ist zwar kein ZConnect-Standard, aber sie wird von CrossPoint bei Fido-Nachrichten benutzt. Diese haben auch bei öffentlichen Nachrichten einen Empfänger, dessen Name hiermit angegeben wird. 4.1.2 Neue Kennungen In diesem Teil finden sich die Kennungen für Suchbedingungen, die kein passendes ZConnect-Äquivalent haben. 4.1.2.1 BODY Hiermit wird der eigentliche Nachrichtentext durchsucht. Es wird jede Zeile der Nachricht einzeln mit dem angegebenen Regulären Ausdruck verglichen. Die Bedingung trifft zu, wenn mind. eine Zeile den zu suchenden Text enthält bzw. - falls der Reguläre Ausdruck mit dem Invertierungszeichen '~' (->S.13) beginnt, um auf Ungleichheit zu testen - wenn keine Zeile paßt. Um z.B. den Text aller Nachrichten nach dem Wort "XPFilter" zu durchsuchen, genügt: BODY=XPFilter Zu beachten ist bei BODY, daß dies die einzige Suchbedingung ist, bei der die Groß-/Kleinschreibweise *nicht* beliebig ist. Eine Nachricht, in deren Text z.B. "XpFiLtEr" steht, würde auf obige Bedingung nicht zutreffen. - 19 - Wichtig ist die Einschränkung des zeilenweisen Vergleichens. Daraus resultiert, daß alle Zeichenketten, die in der Nachricht über ein Zeilenende hinaus- und erst in der nächsten Zeile weitergehen, nicht gefunden werden. 4.1.2.2 BODY-I Diese Suchkennung erledigt genau dasselbe wie BODY (->S.18), mit dem einzigen Unterschied, daß hierbei die Groß-/Kleinschreibweise wieder beliebig ist. 4.1.2.3 GRUPPEN GRUPPEN bietet eine Möglichkeit, je nach Anzahl der öffentlichen Empfänger einer Nachricht bestimmte Aktionen auszuführen. Dafür zählt XPFilter die Zahl der öffentlichen EMP-Headerzeilen und erlaubt neben dem Test auf Gleichheit/Ungleichheit eine numerische Abfrage auf "größer als" und "kleiner als" wie bei LEN (->S.17). Beispielmuster: BRETT=/Müll VERSCHIEBEN GRUPPEN=>10 END Damit werden alle Nachrichten, die mehr als 10 Empfänger haben, in das Brett /Müll verschoben. 4.1.2.4 GRUPPEN-KOP Diese Kennung arbeitet ähnlich wie GRUPPEN. Der einzige Unterschied besteht darin, daß auch die öffentlichen Kopieempfänger (Headerzeile KOP) mitgezählt werden. Das ist hauptsächlich bei Boxprogrammen nützlich, die EMP- in KOP-Zeilen wandeln, wenn das zugehörige Brett nicht bestellt ist (z.B. Zerberus). | 4.1.2.5 IN-ADRBUCH | | Mit dieser Kennung ist ein Test daraufhin möglich, ob der Absender einer | Nachricht bereits in XPs Adreßbuch eingetragen ist. Ist dies der Fall, ist | die Bedingung | | IN-ADRBUCH=1 | | erfüllt, ansonsten | | | - 20 - | | | | IN-ADRBUCH=0 | | Um diese Funktion sinnvoll einsetzen zu können, sollte in XP die | automatische Useraufnahme auf "Nur PMs" gesetzt werden. Ansonsten könnten | sich bei einer riesigen Userdatenbank u.U. auch speichertechnische | Probleme ergeben, da XPFilter alle Einträge aus der Datei USER.DB1 während | des Filterlaufes im Speicher hält. | 4.1.2.6 LAST-BEZ | | LAST-BEZ arbeitet ähnlich wie BEZ (->S.17), mit der Ausnahme, daß es immer | nur die letze in einer Nachricht enthaltene BEZ-Headerzeile beachtet. | | Dies ist laut ZConnect-Standard der direkte Bezug, d.h. die MID der | Nachricht, auf die direkt geantwortet worden ist. Somit lassen sich mit | LAST-BEZ z.B. alle Antworten auf eigene Nachrichten finden, ohne dabei | auch weitere Folgenantworten zu erfassen. 4.1.2.7 QUOTE-ANTEIL Hiermit können je nach Anteil der Quotes in einer Nachricht entsprechende Maßnahmen ergriffen werden. Dabei wird das prozentuale Verhältnis der Anzahl der Quotezeilen zu der Anzahl der Gesamtzeilen ermittelt. Dieses kann mit denselben numerischen Vergleichen, die auch bei LEN (->S.17) möglich sind, abgefragt werden, z.B.: BRETT=/Müll VERSCHIEBEN QUOTE-ANTEIL=>90 END Das Muster verschiebt alle Nachrichten mit mehr als 90% Quotezeilen nach /Müll. Die Art und Weise wie XPFilter eine Quotezeile erkennt kann mit der Aufrufoption -z (->S.50) oder mit der Kennung QUOTE in der Konfigurationsdatei (->S.51) beeinflußt werden. Beachten sollte man, daß nicht jedes ausführliche "Gequote" mit Platzverschwendung gleichzusetzen ist, denn oftmals werden - insbesondere im Usenet - Nachrichten beim Weiterleiten in ein anderes Brett komplett gequotet. 4.1.2.8 QUOTE-ZEILEN Auch hiermit läßt sich je nach Menge der Quotes etwas tun. Im Gegensatz zu - 21 - QUOTE-ANTEIL wird jedoch kein prozentuales Verhältnis ermittelt. Stattdessen läßt sich mit dieser Kennung direkt die Anzahl an Quotezeilen abfragen. Auch hierbei sind natürlich wieder numerische Vergleiche möglich. 4.1.2.9 SUCHEN Mit Hilfe dieser Kennung sind neben den bereits beschriebenen einfachen UND/ODER-Verknüpfungen von mehreren Suchbedingungen auch nahezu beliebig komplexe boolesche Verknüpfungen möglich. Eine genaue Beschreibung dazu findet sich in einem eigenen Kapitel (->S.40). Sie ist an dieser Stelle nur der Vollständigkeit halber aufgeführt. 4.1.2.10 XBET Bewirkt, daß die ZConnect-Headerzeilen BET, STICHWORT und ZUSAMMENFASSUNG gleichzeitig durchsucht werden. Eine Bedingung wie XBET=XPFilter ist gleichbedeutend mit dem SUCHEN-Ausdruck (->S.40) SUCHEN= BET="XPFilter" \ || STICHWORT="XPFilter" \ || ZUSAMMENFASSUNG="XPFilter" 4.2 Aktionen Es folgt eine alphabetische Auflistung aller XPFilter bekannten Aktionen. Man sollte beachten, daß viele dieser Kennungen streng genommen nicht für sich alleine genommen eine Aktion darstellen, sondern eine andere Aktion beeinflussen oder modifzieren. Um das Verständis dieser Kennungen zu erleichtern, sollte als erstes die Beschreibung der "Grundaktion" gelesen werden. Manche Kennungen haben auch - je nachdem mit welchen anderen sie zusammen benutzt werden - unterschiedliche Funktionen. Alle mit "(Schalter)" gekennzeichenten Kennungen benötigen kein weiteres Argument (->S.10). Die meisten Aktionen können auch mehrfach in einem Muster angegeben werden. So läßt sich z.B. mit drei BRETT-Angaben eine Nachricht gleich in drei Bretter kopieren oder mit fünf EXPORT in fünf Dateien exportieren. - 22 - 4.2.1 ABBRUCH (Schalter) Wenn in einem Muster die Kennung ABBRUCH auftaucht, bewirkt dies, daß XPFilter, sobald dieses Muster auf eine Nachricht paßt, die weitere Bearbeitung der Nachricht beendet. Es wird, nachdem die angegebenen Aktionen ausgeführt wurden, zur nächsten Nachricht gesprungen. Alle folgenden Muster werden nicht mehr getestet. Dabei ist zu beachten, daß "alle folgenden" evtl. auch Muster einschließt, die in einer anderen Musterdatei stehen. XPFilter verwaltet die Muster intern in einer langen Liste. Dort stehen zuerst die Muster, die in einer evtl. Konfigurationsdatei (->S.51) aufgeführt sind. Anschließend folgen die Muster aus der Kommandozeile (->S.42). ABBRUCH bewirkt nun, daß alle in *dieser Liste* folgenden Muster für die passende Nachricht nicht mehr weiter beachtet werden (siehe auch Kapitel über Aufrufoptionen (->S.42)). Aufgrund dieser Einschränkung sollte, wenn irgend möglich, die Aktion STOP (->S.38) vorgezogen werden, die sich nur auf die in derselben Datei folgenden Muster bezieht. 4.2.2 AMENDE (Schalter) Dieser Schalter bewirkt, daß alle IMPORT- (->S.29), BATCH- (->S.24) und SENDEN-Aktionen (->S.37) dieses Musters am Programmende, d.h. nachdem der komplette Puffer bearbeitet worden ist, auf jeden Fall einmal ausgeführt werden - egal ob eine Nachricht gepaßt hat oder nicht. Wenn dieser Schalter in einem Muster steht, können auch sämtliche Suchbedingungen weggelassen werden. Dann werden die IMPORT-, BATCH- und SENDEN-Aktionen ausschließlich am Programmende ausgeführt. Da das Muster bei der Bearbeitung am Programmende keine auslösende Nachricht hat, muß für SENDEN auf jeden Fall eine ZIEL-Kennung (->S.40) angegeben werden. Aus dem gleichen Grund ist "SENDEN=*" hierbei nicht möglich. Eine mögliche Anwendung ist z.B. - wenn ein anderes Muster alle passenden Nachrichten in ein eigenes Verzeichnis exportiert (->S.27) - am Ende den Inhalt dieses Verzeichnisses in eine Nachricht einzulesen: AMENDE BATCH=dir C:\EXPDIR >dir.tmp IMPORT=dir.tmp ZIEL=/Inhaltsverzeichnis END - 23 - 4.2.3 ANHAENGEN (Schalter) ANHAENGEN ist ein Schalter für die EXPORT-Kennung (->S.27). Er bewirkt, daß vorhandene Dateien nicht überschrieben werden. Stattdessen wird die neue Nachricht beim Exportieren an die bestehende Datei angehängt. Wird beim Exportieren die PUFFER-Kennung (->S.36) benutzt, entstehen auch beim Anhängen korrekte ZConnect-Puffer. 4.2.4 ARCHIV (Schalter) ARCHIV emuliert die Arbeitsweise von CrossPoints Tastenkombination Alt+P. Das heißt, alle auf das zugehörige Muster passenden Nachrichten werden automatisch im Userfach des jeweiligen Absenders archiviert. Persönliche Nachrichten werden anschließend aus dem Nachrichtenfach gelöscht, öffentliche dagegen bleiben auch an ihrer ursprünglichen Stelle. XPFilter erreicht das Archivieren intern auf folgende Art (ähnlich wie CrossPoint selber): Es wird eine Kopie der ursprünglichen Nachricht angelegt, bei der der Empfänger gleich dem Absender gesetzt wird. In der Kopie wird eine Headerzeile "X-XP-ARC" eingefügt und bei öffentlichen Nachrichten die MID um ein Zeichen nach rechts rotiert. Schließlich wird bei persönlichen Nachrichten noch das Original gelöscht. Dieses Löschen läuft über dieselbe Funktion wie die Aktion LOESCHEN (->S.29), d.h. wenn z.B. ein anderes Muster dieselbe Nachricht verschiebt, wird das Original im Endeffekt nicht entfernt. 4.2.5 ATTRIBUT Ab CrossPoint v3.1 ist es möglich, auf den Status einer Nachricht von außen Einfluß zu nehmen. Entsprechend können Nachrichten ab dieser Version mittels der Aktion ATTRIBUT auf "gelesen", "halten", "löschen" und "farbig" hervorgehoben gesetzt werden, indem einfach das entsprechende Schlüsselwort angegeben wird: ATTRIBUT=löschen Es lassen sich auch mehrere Attribute mit '+' kombinieren: ATTRIBUT=farbig+halten+gelesen Eine Kombination aus "halten" und "löschen" ist allerdings aus verständlichen Gründen nicht möglich. - 24 - Um sich ein bißchen Tipperei zu ersparen, können die Schlüsselwörter wahlweise durch ihren Anfangsbuchstaben abgekürzt werden: ATTRIBUT=f+h+g Falls eine Nachricht bereits im Originalzustand einen derartigen Status besitzt, wird dieser nur dann beibehalten und ggf. erweitert, wenn er von XPFilter selber stammt. Stammt er hingegen aus dem Netz, wird er durch den neuen ersetzt. Dadurch ist gewährleistet, daß sich mehrere Filterläufe in dieser Hinsicht ergänzen können, ohne daß gewisse Schlaumeier Gelegenheit zur Einflußnahme von außen bekommen. 4.2.6 AUSGABE (Schalter) Diese Kennung hat nur eine Wirkung, wenn beim Aufruf die Option -w (->S.50) oder in der Konfigurationsdatei die Kennung SELECTOUTPUT (->S.51) angegeben worden ist. Sie dient dann dazu, das zugehörige Muster in den ausführlichen Bericht aufnehmen zu lassen, der durch die Optionen -o, -p, -v (->S.42) (bzw. VERBOSE, VERBOSESCREEN, VERBOSEMAIL (->S.51) ) ausgelöst wird. Alle Muster ohne AUSGABE erscheinen bei Benutzung der Option -w nicht in dem Bericht. Dadurch läßt sich dessen Umfang auf einfache Weise drastisch reduzieren. 4.2.7 BATCH Die Angabe einer BATCH-Kennung erlaubt es, die angegebene Programm- oder Batchdatei automatisch ausführen zu lassen, sobald eine Nachricht auf das Muster gepaßt hat. Wenn sich die Programm-/Batchdatei nicht im CrossPoint-Verzeichnis oder im aktuellen DOS-Pfad befindet, muß der volle Pfad angegeben werden. Es können auch evtl. Argumente für den Aufruf angefügt werden. Wird BATCH zusammen mit EXPORT (->S.27) benutzt, so wird der Name der Exportdatei beim Aufruf übergeben. Dabei stellt der Name immer das letzte Argument dar, d.h. er wird praktisch einfach an den Inhalt von BATCH angehängt bevor das Programm gestartet wird. Sollten mehrere EXPORT- und BATCH-Angaben in einem Muster vorhanden sein, so bekommt die erste BATCH-Angabe als Argument den ersten EXPORT-Namen, die zweite den zweiten EXPORT-Namen usw. Überschüssige BATCH-Programme, d.h. diejenigen ohne zugehörige EXPORT-Kennung, werden ohne zusätzliches - 25 - Argument gestartet. Jede gestartete Programm- oder Batchdatei bekommt einen *freien* Umgebungsspeicherplatz von mind. 256 Bytes. 4.2.8 BEZIEHEN (Schalter) Diese Kennung darf nur zusammen mit BRETT (->S.25) benutzt werden. Sie ändert deren Verhalten so, daß nun nicht mehr kopiert wird. Stattdessen wird eine *neue* Nachricht von XPFilter in dem angegebenen Brett erzeugt, die mit Hilfe der Bezugsverkettung eine Verbindung zu der auslösenden Nachricht herstellt. Damit ist es innerhalb von CrossPoint möglich, mit der Taste '-' zu der Nachricht zu wechseln, auf die das Muster paßte. Der Vorteil im Vergleich zum Kopieren liegt darin, daß die auslösende Nachricht unverändert vorliegt. Der Nachteil ist, daß nicht nur zum Antworten, sondern auch zum Lesen der Nachricht erst zum Original gewechselt werden muß. 4.2.9 BINAER (Schalter) Die Kennung ist nur als Zusatz zu SENDEN (->S.37) wirksam. Sie gibt an, daß die zu versendene Datei als Binärnachricht verschickt werden soll. Bei SENDEN=* hat BINAER keine Wirkung, da hierbei grundsätzlich der Versandtyp dem der auslösenden Nachricht entspricht. 4.2.10 BRETT Die BRETT-Kennung gibt den Namen des Brettes an, in den die auslösende Nachricht kopiert werden soll. Diese Kennung kann auch mit VERSCHIEBEN (->S.40), BEZIEHEN (->S.25) oder PHYS (->S.36) zusammen in einem Muster stehen und gibt dann für diese Aktionen den entsprechenden Brettnamen an. Es sollte darauf geachtet werdem, daß der Brettname mit dem Zeichen '/' beginnt, da sonst Probleme auftreten können: CrossPoint betrachtet anscheinend alle Nachrichten mit einem Empfänger ohne '/' als persönliche Nachrichten. Eine Konsequenz davon ist z.B., daß alle Absender der entsprechenden Nachrichten in die Userdatenbank aufgenommen werden. 4.2.11 DEBUG Wie der Name schon sagt eine Aktion für Testzwecke. Falls ein Muster, das - 26 - diese Kennung enthält, auf eine Nachricht paßt, hält XPFilter die Bearbeitung an und fragt nach dem weiteren Vorgehen. Je nach Tastendruck führt XPFilter die Aktionen des Musters diesmal, diesmal nicht, immer oder nie aus. Ausserdem kann XPF ohne Aenderung des Puffers beendet werden. Zusätzlich zu dieser Abfrage werden noch einige Informationen ausgegeben, die denen im "Ausführlichen Bericht" (->S.48) ähneln (aber nicht ganz entsprechen, da zu diesem Zeitpunkt noch nicht alle dafür benötigten Daten zur Verfügung stehen). *Vorsicht*: Die Kennung sollte nach dem Testen wieder entfernt werden, da XPFilter ansonsten natürlich auch beim "normalen", evtl. unbeaufsichtigten Filtern stoppt und auf Befehle seines Frauchens oder Herrchens wartet... :-) 4.2.12 DEL (Schalter) Die Kennung DEL ist eine Ergänzung zu EXPORT (->S.27) und bewirkt, daß alle Dateien, in die die auslösende Nachricht exportiert wurde, nach Beendigung aller Aktionen wieder gelöscht werden. 4.2.13 EINMAL (evtl. Schalter) Ohne weitere Parameterangabe bewirkt diese Kennung, daß alle Aktionen des Musters nur einmal für jeden Absender durchgeführt werden. Sollten also mehrere Nachrichten eines Absenders auf das Muster passen, werden ab einschließlich der zweiten alle folgenden ignoriert. Wird zusätzlich ein Dateiname angeben, z.B. EINMAL=c:\tmp\emps.dat werden in der Datei alle bisherigen Absender gespeichert. Dadurch bleibt die Adressenliste auch zwischen mehreren Filterläufen erhalten. Das ganze kann z.B. nützlich sein, wenn man einige Zeit nicht zu Hause ist und mit Hilfe von SENDEN (->S.37) auf persönliche Nachrichten mit einer automatischen Antwort reagieren lassen möchte. In ein derartiges Muster könnte dann EINMAL eingefügt werden. Dadurch wird - auch wenn jemand mehrere Nachrichten sendet - nur eine automatische Antwort zurückgeschickt. Sobald die angegebene EINMAL-Datei gelöscht wird, geht das das ganze wieder von vorne los, d.h. jeder erhält wieder eine Nachricht und seine Adresse wird anschließend in der Datei gespeichert. - 27 - Zu beachten ist, daß bei der Benutzung einer Datei u.U. relativ viel Speicher benötigt wird, falls viele Empfänger eine Nachricht geschickt bekommen. 4.2.14 ERHALTEN (Schalter) Hiermit wird erreicht, daß alle auf das zugehörige Muster passenden Nachrichten auf keinen Fall gelöscht werden, selbst wenn andere Muster dieses gerne möchten (->S.29). Die entsprechenden Nachrichten können wie gewohnt verschoben oder kopiert werden. Hätte allerdings eine der Nachrichten nach Bearbeitung aller Muster keinen Empfänger mehr, so würden die ursprünglichen wieder eingesetzt. Zusätzlich würde XPFilter in einem solchen Fall eine kurze Notiz an den Nachrichtenanfang setzen. Eine ähnliche Funktion hat ERHALTEN auf ein von ATTRIBUT (->S.23) gesetztes "Löschen"-Flag: Es wird wieder entfernt. Global läßt sich dieses Verhalten für alle MARKIEREN- (->S.30) und BEZIEHEN-Muster (->S.25) mit Hilfe der Option -y (->S.50) aktivieren. 4.2.15 EXPORT EXPORT weist XPFilter an, die auslösende Nachricht in die angegebene Datei zu kopieren. Wenn der Dateiname ohne Pfad angegeben wird, legt XPFilter sie im CrossPoint-Verzeichnis an. Bereits vorhandene Dateien werden überschrieben - es sei denn, im selben Muster ist die Kennung ANHAENGEN (->S.23) angegeben. Eine Besonderheit ergibt sich, wenn der Name eines vorhandenen Verzeichnisses angegeben wird. XPFilter exportiert dann alle passenden Nachrichten in dieses Verzeichnis, wobei es den Dateinamen selbst | generiert. Dafür wird - falls vorhanden - der Inhalt einer FILE- oder U- | CONTENT-DISPOSITION-Headerzeile benutzt. Ansonsten werden einfach die ersten elf Zeichen des Betreffs genommen - allerdings ohne Leerzeichen (genauer: ohne "Whitespaces"). Eine weitere Möglichkeit, die Dateinamen automatisch generieren zu lassen, besteht in der Verwendung des '$'-Zeichens. XPFilter ersetzt alle '$' innerhalb eines Dateinamens durch eine fortlaufende Numerierung. Z.B. würden bei einer Musterzeile wie EXPORT=c:\tmp\message.$$$ die Namen der erzeugten Dateien z.B. "c:\tmp\message.001", "c:\tmp\message.002", "c:\tmp\message.003" usw. lauten. Dabei beachtet - 28 - XPFilter alle evtl. bereits in einem anderen Filterlauf oder von einem anderen Muster auf diese Weise erzeugten Dateien und generiert ausschließlich noch freie Nummern. Dadurch ist gewährleistet, daß vorhandene Dateien nicht überschrieben werden. Sollten keine Nummern mehr verfügbar sein, wird eine Warnung ausgegeben und nicht exportiert. Diese automatische Numerierung funktioniert nicht, wenn gleichzeitig ANHAENGEN (->S.23) benutzt wird. In einem solchen Fall werden die '$'-Zeichen ohne Änderung beibehalten. Standardmäßig wird nur der eigentliche Nachrichtentext in die Datei exportiert. Mit Hilfe von PUFFER (->S.36) kopiert XPFilter aber auch den Nachrichtenheader mit und erzeugt damit korrekte ZConnect-Puffer. Z.B. ist es - wenn PUFFER und ANHAENGEN zusammen mit EXPORT benutzt werden - möglich, aus allen passenden Nachrichten einen neuen ZConnect-Puffer erstellen zu lassen, der anschließend mit entsprechenden Programmen weiterverarbeitet werden kann. Bei EXPORT sind keine Variablenersetzungen möglich (->S.53). 4.2.16 GRUND (Schalter) Dieser Schalter bewirkt, daß XPFilter bei einer auf dieses Muster passenden Nachricht die Zeichenfolgen, die auf eine Suchbedingung (->S.11) paßten, an den Beginn des Nachrichtentextes schreibt. Damit kann man auf einen Blick sehen, welches Muster diese Nachricht warum bearbeitet hat. Bei einem Muster wie NAME=Rund um XPFilter BRETT=/XPFilter BET=xpfilter|xpf[0-9]+\.arj GRUND END und einer Nachricht mit dem Betreff Neu: XPF140.ARJ würde z.B. folgendes an den Beginn der Nachricht geschrieben: ## Muster *Rund um XPFilter* ## BET: XPF140.ARJ Es erscheinen also immer die Textteile aus der Nachricht, die auf einen - 29 - Regulären Ausdruck gepaßt haben. Dabei ist allerdings die Anzahl der insgesamt ausgegebenen Treffer auf max. 15 begrenzt. Keine Regel ohne Ausnahmen: Die passenden Zeichenfolgen werden nur bei Test auf Gleichheit ausgegeben. Bei einer Bedingung wie z.B. BODY=~xpfilter geschieht dies nicht, da die Bedingung ja auf alle Zeilen der Nachricht zutreffen würde... Stattdessen wird nur der Name der passenden Kennung ausgegeben. Die zweite Ausnahme bilden Binärnachrichten. Auch hier erfolgt - aus verständlichen Gründen - keine Veränderung des Nachrichtentextes. 4.2.17 IMPORT Mit IMPORT ist es möglich, eine beliebige Textdatei als Nachricht in den Puffer zu übernehmen. Dafür muß als Inhalt der Dateiname angegeben werden. Dieser muß, falls sich die Datei nicht im CrossPoint-Verzeichnis befindet, den vollen Pfad beinhalten. Das Brett, in dem die Nachricht abgelegt wird, muß mit der ZIEL-Kennung (->S.40) angegeben werden, der Betreff kann mit TITEL (->S.39) bestimmt werden (ansonsten stellt der Dateiname den Betreff dar). Der Text der Nachricht kann dieselben Makros enthalten wie CrossPoints Schablonen. Näheres dazu findet sich bei SENDEN (->S.37). Es können auch die DOS-Wildcards '*' und '?' benutzt werden, wobei aus jeder passenden Datei jeweils eine neue Nachricht erstellt wird. Eine Anwendungsmöglichkeit des Importierens ist z.B. das Einlesen von Programmausgaben, die mit Hilfe der BATCH-Kennung (->S.24) erzeugt wurden. Aufgrund der Benutzung von ZIEL und TITEL kann IMPORT nicht zusammen mit SENDEN (->S.37) im selben Muster benutzt werden. 4.2.18 INAKTIV Mit INAKTIV wird schlicht ein ganzes Muster deaktviert und von XPFilter nicht mehr beachtet. Dies kann z.B. für Testzwecke nützlich sein. 4.2.19 LOESCHEN (evtl. Schalter) LOESCHEN als Schalter benutzt bewirkt genau das, was der Name sagt: Alle - 30 - auf dieses Muster passenden Nachrichten werden aus dem Puffer entfernt. Eine Ausnahme existiert: Wenn auch andere Muster auf diese Nachricht zutreffen, sie aber Kopieren oder Verschieben möchten, so werden durch LOESCHEN nur die Originalempfänger gelöscht. D.h. alle Empfänger, die von XPFilter selber erzeugt werden, bleiben vorhanden. Die gesamte Nachricht wird nur dann komplett aus dem Puffer entfernt, wenn sie nach Prüfung aller Muster keinen Empfänger mehr hat. Dadurch ist gewährleistet, daß, wenn ein Muster die Nachricht gerne gelöscht hätte, ein anderes sie aber für äußerst wichtig betrachtet, die Nachricht im Puffer bleibt (Ausnahme von der Ausnahme: LOWPRIO (->S.30)). Außerdem läßt sich das Löschen auch noch mit ERHALTEN (->S.27) sowie mit der Option -z (->S.50) (bzw. mit KEEPMAILS in der Konfigurationsdatei) verhindern. | Eine etwas speziellere Variante des Löschens läßt sich mit Hilfe eines | zusätzlich angegebenen Regulären Ausdrucks (->S.73) erreichen. Es werden | dann nur die EMPs aus den Nachrichten entfernt, auf die der Ausdruck paßt: | | LOESCHEN=^/comp/windows | | Damit werden z.B. alle EMPs, die ein Brett aus der | "/comp/windows"-Hierarchie enthalten, entfernt. 4.2.20 LOWPRIO (Schalter) Dieser Schalter ist nur in Verbindung mit BRETT (->S.25) erlaubt und bewirkt, daß alle Kopier- und Verschiebeaktionen mit einer Art niedriger Priorität durchgeführt werden. Dadurch werden die neuen EMPs im folgenden behandelt als seien sie bereits in der Originalnachricht vorhanden gewesen. Als Konsequenz können sie durch ein LOESCHEN (->S.29) eines anderen Musters wieder entfernt werden. 4.2.21 MARKIEREN (evtl. Schalter) Diese Aktion bietet eine Möglichkeit, Nachrichten in der Nachrichtenübersicht ins Auge fallen zu lassen, ohne sie extra in ein spezielles Brett kopieren lassen zu müssen. Dazu bedient sich XPFilter folgenden Tricks: Bei einer passenden Nachricht wird der Realname verändert. Dabei wird er zuerst mit Hilfe von Leerzeichen auf eine Länge von 26 Zeichen vergrößert. Anschließend wird das 26. Zeichen durch ein '*' ersetzt. Um den Effekt feststellen zu können, muß in CrossPoint die Realnamenanzeige eingestellt sein. Dies ist, wenn nicht bereits geschehen, - 31 - entweder kurzzeitig über die Tastenkombination CTRL+N oder dauerhaft über den Menüpunkt "Config/Anzeige.../Nachrichten/Realname anzeigen" möglich. Als Beispiel, wie das Ergebnis eines Musters mit MARKIEREN aussehen könnte, folgender fiktiver Ausschnitt aus einer Nachrichtenübersicht: > 123 John Smith Wer bin ich? > 321 Alex * Hier komm ich! > 213 Bart Simpson Goldfish don't bounce Die mittlere Nachricht ist "markiert" worden und fällt dadurch sofort ins Auge. Wenn mehrere MARKIEREN-Muster auf eine Nachricht passen, wird der Realname ab dem 26. Zeichen rückwarts aufgefüllt, d.h. bei zwei passenden Mustern erscheinen zwei Sternchen in der Nachrichtenübersicht usw. Ein mögliches Ergebnis von mehreren Treffern wäre z.B.: > 123 John Smith ** Wer bin ich? > 321 Alex ******* Hier komm ich! > 213 Bart Simpson **** Goldfish don't bounce Desweiteren lassen sich bei MARKIEREN auch andere Zeichen bzw. ganze Zeichenketten angeben, die dann anstatt des Sternchens benutzt werden. So wird mit MARKIEREN=! ein Ausrufezeichen in den Realnamen eingesetzt und mit MARKIEREN=--> erschiene in der Nachrichtenübersicht z.B. > 123 John Smith Wer bin ich? > 321 Alex --> Hier komm ich! > 213 Bart Simpson Goldfish don't bounce Falls ein Realname so lang ist, daß die entsprechende Zeichenkette zum Markieren nicht mehr genügend Platz hätte, wird er aufgeteilt, d.h. die Markierung wird an der entsprechenden Stelle eingefügt. Der Rest des Realnames rückt einfach ein Stück weiter nach hinten und ist jederzeit im Nachrichtenkopf erkennbar. Wenn eine Nachricht gar keinen Realnamen besitzt, wird die Adresse als "Ersatz-Realname" genommen. Sie wird entsprechend markiert und in Klammern in die ABS-Headerzeile eingefügt. - 32 - Aber das MARKIEREN hat auch Nachteile: Der größte ist wohl, daß es schlicht nicht in allen Netzen funktioniert. Im Usenet und im Z-Netz gibt es keine Probleme, aber z.B. im Fido nützt es gar nichts, da CrossPoint einen in Klammern angegebenen Realnamen schlicht nicht beachtet. Im Zweifelsfall hilft nur probieren... Ein zweiter Nachteil liegt in dem veränderten Realnamen selber. So erscheint die Markierung innerhalb des Namens z.B. in Quoteschablonen, die entsprechende Makros benutzen. Dies muß dann per Hand abgeändert werden, wenn die Markierung nicht mit in die weite Welt geschickt werden soll. Und als dritter, geringfüger Nachteil: Im Kommentarbaum sieht das ganze optisch nicht immer sonderlich elegant aus... :-) 4.2.22 N-ANTWORT-AN Mit N-ANTWORT-AN ist es möglich, die ANTWORT-AN-Headerzeile innerhalb einer Nachricht zu setzen, z.B. N-ANTWORT-AN=lisa@simpsons.edu Falls eine Nachricht allerdings bereits eine solche Headerzeile enthält, bleibt diese unangetastet, d.h. die Aktion bleibt in dem Fall wirkungslos (anders verhält es sich, wenn statt N-ANTWORT-AN die Aktion N-HEADER (->S.33) benutzt wird). 4.2.23 N-DISKUSSION-IN (evtl. Schalter) Diese Aktion ermöglicht es, bei allen passenden Nachrichten eine DISKUSSION-IN-Headerzeile einzufügen. Dadurch lassen sich z.B. alle eigenen Antworten auf diese Nachrichten in ein anderes Brett leiten, auch wenn der Schreiber dies nicht vorgesehen hat. Ein Beispiel: NAME=XP Tools: DISKUSSION-IN setzen EMP=/t-netz/support/xpoint/tools N-DISKUSSION-IN=/t-netz/support/xpoint/allgemeines END Alle Nachrichten, die im CrossPoint-Toolsbrett hereinkommen, erhalten automatisch eine DISKUSSION-IN-Zeile, die auf das allgemeine CrossPoint- Brett zeigt - der richtige Ort für Antworten. Im Gegensatz zu CrossPoints "Vertreter", der sich zu jedem Brett eintragen läßt, sind aber trotzdem eigene Nachrichten im Toolsbrett problemlos möglich. - 33 - Noch zwei Anmerkungen zu N-DISKUSSION-IN: Falls eine Nachricht bereits eine DISKUSSION-IN-Headerzeile besitzt, wird diese nicht verändert, denn man sollte wohl davon ausgehen können, daß der Schreiber sich überlegt hat, wo er die Antworten lesen möchte (sollte dennoch gewünscht sein, ggf. vorhandene DISKUSSION-IN zu überschreiben, ist N-HEADER (->S.33) die bessere Wahl). Desweiteren arbeitet diese Aktion etwas abgewandelt, wenn sie als Schalter benutzt wird, d.h. wenn kein Brett angegeben wird. Sie setzt dann kein DISKUSSION-IN, sondern, im Gegenteil, verhindert, daß ein DISKUSSION-IN für diese Nachrichten von anderen Aktionen (z.B. von BRETT (->S.25) oder VERSCHIEBEN (->S.40)) gesetzt wird. 4.2.24 N-HEADER Diese Kennung stellt eine etwas gefährliche Aktion dar. Sie sollte nur mit größter Vorsicht benutzt werden, und man ist sicher in den meisten Fällen gut beraten, wenn man ihren Einsatz zuerst gründlich überdenkt. Mit N-HEADER kann man fast beliebigen Einfluss auf einen Nachrichtenkopf nehmen. Es lassen sich nahezu ohne Begrenzung Headerzeilen löschen, ändern oder hinzufügen. Für die Syntax gibt es im Wesentlichen zwei Möglichkeiten. Zum Löschen einer Headerzeile dient '~'. Mit N-HEADER=~STICHWORT werden z.B. sämtliche STICHWORT-Headerzeilen aus der Nachricht entfernt. Zum Setzen einer Headerzeile wird der neue Inhalt benötigt: N-HEADER=STICHWORT:Simpsons fügt eine neue STICHWORT-Headerzeile hinzu. Beim Setzen einer Headerzeile unterscheidet XPFilter zwei Fälle: Alle Headerzeilen, die laut ZConnect-Standard mehrfach erlaubt sind, werden ganz einfach hinzugefügt. Dagegen werden Zeilen, die nur einmal existieren dürfen, gegen den neuen Inhalt ausgetauscht. Beim Löschen einer Headerzeile werden grundsätzlich alle entfernt. Das kann man ausnutzen, um auch die Headerzeilen zu ersetzen, die mehrfach vorkommen dürfen. Kombiniert man z.B. die vorherigen beiden Beispiele zu N-HEADER=~STICHWORT N-HEADER=STICHWORT:Simpsons - 34 - werden alle ursprünglichen STICHWORT-Headerzeilen entfernt und anschließend eine neue mit "Simpsons" hinzugefügt. Beim Setzen einer Headerzeile sind auch leere Inhalte möglich: N-HEADER=EB Damit wird der Nachricht der Status einer Empfangsbestätigung gegeben. An zu setzenden oder zu löschenden Headerkennungen können all diejenigen benutzt werden, die auch bei Suchbedingungen (->S.11) möglich sind - einschließlich der in der XPFILTER.DEF-Datei (->S.52) definierten. Bei N-Header gibt es zwei Sonderfälle: 1. Es läßt sich mit dieser Kennung kein Einfluss auf EMP-Headerzeilen nehmen, da dieses sich weitaus besser mittels BRETT (->S.25) und Konsorten machen läßt. 2. Wenn die Headerzeilen KOP oder DISKUSSION-IN mittels N-HEADER gelöscht werden, bewirkt dies zusätzlich, daß sie auch von anderen Aktionen (z.B. BRETT (->S.25)) nicht mehr erzeugt werden. In diesem Fall können lediglich weitere N-HEADER-Aktionen darauf Einfluss nehmen. Allgemein gilt: N-HEADER hat Priorität vor allen anderen Aktionen, die ggf. dieselbe(n) Headerzeile(n) beeinflussen würden. Außerdem nimmt N-HEADER beim Ersetzen einer Headerzeile keine Rücksicht auf bisherige Inhalte. So sind z.B. für ANTWORT-AN und DISKUSSION-IN in den meisten Fällen wohl die entsprechenden Aktionen N-ANTWORT-AN (->S.32) und N-DISKUSSION-IN (->S.32) angebrachter. Als letztes nochmal die Warnung: Die Benutzung dieser Aktion erfolgt vollständig auf eigene Gefahr, XPFilter nimmt nicht den geringsten Plausibilitätstest der entstehenden Nachricht vor. Es ist also ein leichtes, mit N-HEADER einen kompletten Puffer auf weiteres unbrauchbar zu machen... You've been warned! 4.2.25 N-STICHWORT Hiermit wird allen passenden Nachrichten eine neue STICHWORT-Headerzeile mit dem angegebenen Inhalt hinzugefügt. CrossPoint läßt sich so einrichten, daß diese Zeile im Nachrichtenlister angezeigt wird. Außerdem übernimmt CrossPoint diese Headerzeile auch in eine evtl. Antwort. Man sollte daher keinen langen Text angeben, sondern sich wirklich auf ein Stichwort beschränken, das auch bei Antworten noch - 35 - sinnvoll zum Inhalt paßt. 4.2.26 NAME Mit Hilfe dieser Kennung ist es möglich, jedem Muster einen kurzen "Namen" zu geben. Normalerweise werden die Muster der Reihe nach duchnumeriert und in den Berichten (->S.42) und ähnlichen Ausgaben erscheint dann etwas wie "42 Nachrichten gelöscht von Muster 24". Wenn jedoch für das betreffende Muster eine NAME-Kennung vorhanden ist, werden die wenig aussagekräftigen Nummern dadurch ersetzt. Lautet z.B. eine Musterzeile NAME=Meine Post so würde obige Ausgabe dann folgendermaßen aussehen: 42 Nachrichten gelöscht von Muster *Meine Post* 4.2.27 ORIGINAL (Schalter) ORIGINAL kann nur zusammen mit SENDEN (->S.37) und BINAER (->S.25) verwendet werden. Ohne diese Kennung legt XPFilter für jede zu versendende Datei eine Kopie an, die erst gelöscht wird, wenn CrossPoint sie wirklich abgeschickt hat. Wenn ORIGINAL benutzt wird, dann wird diese Kopie nicht angelegt. Stattdessen wird CrossPoint die Originaldatei als die zu versendende mitgeteilt. Die Vorteile liegen darin, daß erstens die erzeugte FILE-Headerzeile den korrekten Dateinamen enthält und daß zweitens Festplattenplatz gespart wird. Der Nachtteil ist, daß zum Zeitpunkt des Netzanrufes die Datei auf jeden Fall noch in unverändertem Zustand vorhanden sein muß. Es darf also z.B. keine Datei sein, die über EXPORT (->S.27) extrahiert wird, da diese u.U. bei der nächsten passenden Nachricht gleich wieder überschrieben werden kann. Dafür, daß die Datei unverändert vorliegt, ist einzig und allein der Benutzer verantwortlich... - 36 - 4.2.28 PHYS (Schalter) PHYS darf nur zusammen mit einer BRETT-Kennung (->S.25) in einem Muster vorkommen und bewirkt eine Abwandlung des normalen Kopierens. Während BRETT alleine kopiert, indem der betreffenden Nachricht einfach eine neue 'EMP:'-Headerzeile hinzugefügt wird, arbeitet PHYS anders. Hierbei wird die *gesamte* Nachricht kopiert, d.h. es entsteht kein CrossPosting, sondern eine echte - physikalische - Kopie. Die Nachricht ist anschließend also doppelt im Puffer vorhanden. Der Vorteil ist, daß die Originalnachricht unverändert bleibt. Wenn gleichzeitig andere Muster auf diese Nachricht zutreffen, werden außerdem Veränderungen, die diese Muster evtl. tätigen, an der Kopie vorgenommen. Das Original wird nicht mehr angetastet. Der - schwerwiegende - Nachteil ist die u.U. *starke* Vergrößerung des Nachrichtenpuffers. 4.2.29 PUFFER (Schalter) Dieser Schalter ändert das Verhalten von EXPORT (->S.27) derart, daß nun die gesamte Nachricht, d.h. Nachrichtenheader und Nachrichtentext in die entsprechende Datei geschrieben wird. Dadurch stellt die Datei anschließend einen korrekten ZConnect-Puffer dar, der ggf. weiterbearbeitet werden kann. 4.2.30 REIMPORT (evtl. Schalter) Mit Hilfe dieser Kennung ist es möglich, allen auf dieses Muster passenden Nachrichten einen neuen Nachrichtentext zu geben. Dazu wird der alte Nachrichtentext komplett entfernt und der Inhalt der angegebenen Datei als neuer Text eingelesen. Der Nachrichtenheader wird nicht verändert (der Betreff läßt sich - wie sonst auch - mit Hilfe von TITEL (->S.39) ändern, der Rest, wenn es unbedingt sein muß, mit N- HEADER). Wird REIMPORT als Schalter benutzt, d.h. wird kein Dateiname angegeben, muß im selben Muster genau eine EXPORT-Kennung (->S.27) vorhanden sein. Es wird dann der Inhalt der Datei, in die die Nachricht vorher exportiert wurde, wieder eingelesen. Zwischenzeitlich es ist möglich, die Datei mit Hilfe der BATCH-Kennung (->S.24) zu verändern. - 37 - 4.2.31 SENDEN Die SENDEN-Kennung dient zum automatischen Verschicken von Nachrichten. Alle Nachrichten, die verschickt werden sollen, müssen dafür als Datei vorliegen. Der Dateiname wird SENDEN als Inhalt zugewiesen, z.B.: SENDEN=C:\DATEI.TXT Damit wird bei jeder passenden Nachricht die Datei "C:\DATEI.TXT" verschickt. Der Empfänger ist standardmäßig der Absender der auslösenden Nachricht. Die Datei wird also praktisch als Antwort zurückgeschickt. Einen anderen Empfänger kann man mit der ZIEL-Kennung (->S.40) angeben. Der Betreff der verschickten Datei ist normalerweise der Dateiname, aber mit Hilfe von TITEL (->S.39) kann man auch einen neuen Betreff wählen. Normalerweise wird der Inhalt der Datei behandelt, als ob es eine Textdatei wäre. Soll eine binäre Datei verschickt werden, muß unbedingt der BINAER-Schalter (->S.25) ins Muster aufgenommen werden, da die Datei ansonsten mit Sicherheit als elektronischer Datenschrott ihren Empfänger erreicht... :-) Bei Textnachrichten ist es möglich, alle von CrossPoint her bekannten Schablonenmakros zu benutzen. XPFilter versucht diese, soweit praktikabel, zu emulieren. Eine genau Beschreibung findet sich der Einfachheit halber in Kapitel 3.6, Unterpunkt "Makros", innerhalb der CrossPoint Dokumentation sowie in dessen Onlinehilfe (Edit/Schablonen//Makros). XPFilter setzt bei den Schablonen allerdings kein evtl. bei einem User eingetragenes "Pseudo" ein, sondern tut stattdessen so, als ob dieser Eintrag nicht vorhanden wäre. :-) Wenn die SENDEN-Funktion benutzt wird, sollte nach dem Filterlauf das AUTOEXEC-Verzeichnis abgearbeitet werden. Dies geschieht spätestens beim nächsten Start von CrossPoint automatisch. Näheres zum AUTOEXEC- Verzeichnis findet sich im Handbuch von CrossPoint. Die Datei, die verschickt wird, kann anschließend überschrieben oder gelöscht werden, da auf jeden Fall eine Kopie angelegt wird, die erst verschwindet, wenn CrossPoint die Nachricht wirklich abgeschickt hat (Ausnahme: Wenn ORIGINAL (->S.35) benutzt wird, ist dies nicht der Fall.) Der Server, über den die Nachricht verschickt wird, ist standardmäßig der, der für den betreffenden User eingetragen ist. Steht dieser noch nicht im Adreßbuch, wird die Stammbox benutzt. Ein anderer Server läßt sich global mit Hilfe der Aufrufoption -s (->S.48) oder lokal, d.h. nur auf das zugehörige Muster bezogen, mit der Kennung SERVER (->S.38) angeben. - 38 - Beim Namen der zu verschickenden Datei können auch die DOS-Wildcards '*' und '?' benutzt werden, wodurch jede passende Datei jeweils einzeln verschickt wird. Neben diesem normalen Senden von Dateien gibt es auch noch einen "Weiterleitmodus". Er kann dazu benutzt werden, alle auf ein Muster passenden Nachrichten an eine beliebige Adresse weiterzuleiten. Eingeschaltet wird der Modus, indem der Inhalt von SENDEN aus genau einem Sternchen besteht: SENDEN=* Voraussetzung dafür ist, daß im selben Muster eine (nicht mehrere) EXPORT- Kennung vorhanden ist. XPFilter exportiert die Nachricht zuerst in die Datei und verschickt diese dann. Der Empfänger der weitergeleiteten Nachrichten sollte *unbedingt* mit ZIEL (->S.40) angegeben werden, da ansonsten jeder Absender seine eigene Nachricht zurückgeschickt bekommt.... Der Betreff ist normalerweise der gleiche wie bei der auslösenden Nachricht, läßt sich aber mit TITEL (->S.39) ändern. Die Angabe von BINAER ist im Weiterleitmodus nicht erlaubt, da der Typ der verschickten Nachricht immer dem der auslösenden entspricht. Anzumerken ist vielleicht noch, daß diese Weiterleitung recht rudimentär ist. Vom Betreff abgesehen gehen dabei sämtliche Headerinformationen verloren... Aufgrund der Benutzung von ZIEL und TITEL kann SENDEN nicht zusammen mit IMPORT (->S.29) im selben Muster benutzt werden. 4.2.32 SERVER Diese Kennung ist nur zusammen mit SENDEN (->S.37) benutzbar und gibt den Namen des Servers an, über den die entsprechenden Nachrichten verschickt werden sollen. Fehlt diese Kennung, wird, falls vorhanden, der global mit der Option -s (->S.48) eigestellte Server benutzt. Ansonsten nimmt CrossPoint den für den jeweiligen Empfänger eingetragenen Server bzw. die Stammbox. 4.2.33 STOP (Schalter) STOP arbeitet ähnlich wie ABBRUCH (->S.22). Sobald ein diese Kennung enthaltendes Muster auf eine Nachricht gepaßt hat, werden alle *in - 39 - derselben Musterdatei* folgenden Muster für *diese* Nachricht nicht mehr beachtet. Stattdessen wird mit der Bearbeitung zur nächsten Musterdatei gesprungen bzw., falls keine weitere mehr vorhanden ist, mit der nächsten Nachricht fortgefahren. Zusammen mit ABBRUCH stellt STOP die einzige Aktion dar, bei der die Reihenfolge der Muster innerhalb der Musterdateien nicht beliebig ist, sondern eine Auswirkung auf das Ergebnis hat. 4.2.34 SWAP (evtl. Schalter) Diese Kennung ist ein Zusatz zu BATCH (->S.24). Es kann sein, daß ein per BATCH aufgerufenes Programm mehr DOS-Speicher benötigt, als die bereits im RAM stehenden Programme CrossPoint und XPFilter übriglassen. Mit dieser Kennung läßt sich in KByte angeben, wieviel RAM das aufzurufende Programm mindestens benötigt. Falls weniger zur Verfügung steht, lagert sich XPFilter zusammen mit seinen Daten in den Expansions- oder Erweiterungsspeicher (XMS oder EMS) aus - falls dieser in genügender Menge vorhanden ist. Falls nicht, wird eine temporäre Datei auf der Festplatte erzeugt, in die der von XPFilter belegte Speicher für die Dauer der BATCH-Ausführung kopiert wird. Sollte auch nach dem Auslagern nicht der gewünschte Platz zur Verfügung stehen, wird das Programm dennoch gestartet. Die folgende Musterzeile würde z.B. bedeuten, daß bei der BATCH-Ausführung mind. 400 KB vorhanden sein sollen: SWAP=400 Werden 0 KByte angegeben oder wird der Parameter ganz weggelassen, lagert sich XPFilter auf jeden Fall aus, egal wieviel Speicher noch frei ist: SWAP 4.2.35 TITEL Die TITEL-Kennung hat drei verschiedene Funktionen: 1. Zusammen mit SENDEN (->S.37) gibt sie den Betreff der zu verschickenden Nachricht an. 2. In Kombination mit IMPORT (->S.29) gibt sie den Betreff der importierten Nachricht an. - 40 - 3. Ansonsten ändert sie den Betreff aller auf dieses Muster passenden Nachrichten entsprechend. 4.2.36 TEXT Die Aufgabe der TEXT-Kennung besteht einfach darin, am Beginn aller passenden Nachrichten eine neue Textzeile mit dem angegebenen Inhalt einzufügen (gilt nicht bei Binärnachrichten). 4.2.37 VERSCHIEBEN (Schalter) Dieser Schalter, der nur als Ergänzung zur BRETT-Kennung (->S.25) erlaubt ist, bewirkt, daß alle passenden Nachrichten in das Brett verschoben werden anstatt kopiert. Das bedeutet, daß die Nachrichten anschließend nur noch in diesem Brett erscheinen. Dabei werden standardmäßig (->S.50) alle alten EMP- Headerzeilen durch KOP ersetzt, damit auch im nachhinein noch der Ursprung erkennbar bleibt. 4.2.38 ZIEL ZIEL besitzt eine Doppelfunktion. Wenn es zusammen mit SENDEN (->S.37) in einem Muster steht, gibt es die Zieladresse der verschickten Datei an. Ist allerdings IMPORT (->S.29) stattdessen vorhanden, so bezeichnet ZIEL das Brett, in dem die importierte Nachricht erscheint. 4.3 Die SUCHEN-Kennung Mit den bisher beschriebenen Möglichkeiten, Suchbedingungen zu formulieren, lassen sich bereits eine große Anzahl von Mustern sinnvoll erstellen. Allerdings gibt es auch Muster, bei denen es nötig oder zumindest ganz praktisch wäre, wenn man diverse Verknüpfungen zwischen den Suchbedingungen angeben könnte. Dafür gibt es die SUCHEN-Kennung. Der Inhalt stellt einen booleschen Ausdruck dar, d.h. eine beliebige Kombination von Suchbedingungen, die gleichzeitig oder wahlweise erfüllt sein sollen. Vorweg ein Beispiel: SUCHEN= ( EMP="/BRETT1" || LEN>"12k" ) && ABS!="H\.Meier@dose" Der Inhalt besteht aus einzelnen Suchbedingungen, in dem Beispiel sind es drei Stück. Die Syntax dieser Suchbedingungen unterscheidet sich allerdings etwas von der, wie sie außerhalb der SUCHEN-Kennung benutzt wird. - 41 - Die Namen der Kennungen (im Beispiel EMP, LEN, ABS) sind dieselben, aber der zu vergleichende Reguläre Ausdruck muß in *Anführungszeichen* eingeschlossen werden. Um auf Gleicheit zu testen, wird das Zeichen '=' benutzt, für Ungleichheit steht die Kombination '!='. In dem Beispiel ist mit ABS!="H\.Meier@dose" also jeder Absender gemeint, der nicht "H.Meier@dose" enthält. Desweiteren kann bei numerischen Kennungen wie LEN, GRUPPEN u.ä. noch auf "kleiner als" (<) und "größer als" (>) getestet werden. Wird dabei als Vergleichswert eine einfache Zahl angegeben, können die Anführungszeichen weggelassen werden. Allerdings kann man die Vergleichszahl auch in KByte angeben, indem man - wie in dem Beispiel - ein 'k' anfügt. Dann werden die Anführungszeichen wieder benötigt. Zur Verbindung der einzelnen Suchbedingungen müssen noch die gewünschten Verknüpfungen angebenen werden. Dazu gibt es '&&' für eine UND- Verknüpfung, d.h. sowohl die links als auch die rechts davon stehende Suchbedingung muß erfüllt sein. Für eine ODER-Verknüpfung steht '||', d.h. es reicht, wenn eine der beiden Bedingungen zutrifft. Eine weitere Möglichkeit, die Bewertung der Suchbedingungen zu beeinflussen, sind die Klammern. Einzelne Teilausdrücke lassen sich klammern, um zu erzwingen, daß sie als erstes bewertet werden. Die Klammern lassen sich nahezu beliebig schachteln. Zwischen den einzelnen Bestandteilen des Ausdrucks können beliebig Leerzeichen eingefügt werden. Wichtig ist, daß der komplette SUCHEN- Ausdruck in einer logischen Zeile stehen muß. Wenn er zu lang wird, sollte die Zeile ggf. mit '\' umbrochen werden (->S.9). Wenn man dies alles nun auf das obige Beispiel überträgt, kann man es folgendermaßen "übersetzen": Der gesamte boolesche Ausdruck und damit die SUCHEN-Kennung trifft zu, wenn eine Nachricht entweder als Empfänger das "/Brett1" oder eine Länge von mehr als 12288 Bytes (1 KByte = 1024 Bytes) hat. Außerdem muß die Nachricht auf jeden Fall einen Absender haben, der nicht "H.Meier@dose" enthält. Ein weiteres Beispiel: SUCHEN= LEN > 200 \ && ( EMP="/news/answers|/de/answers" || BET="FAQ" ) Die Bedingung EMP="/news/answers|/de/answers" macht sich hierbei zunutze, daß auch die Regulären Ausdrücke eine ODER-Verknüpfung vornehmen können (->S.73). Es ist gleichbedeutend mit - 42 - SUCHEN= LEN > 200 \ && ( ( EMP="/news/answers" || EMP="/de/answers" ) \ || BET="FAQ ) ) Eine derartige SUCHEN-Kennung kann nun wie jede normale Suchbedingung in ein Muster aufgenommen werden: BRETT=/XPFilter SUCHEN= ( EMP="/BRETT1" || LEN>"12k" ) && ABS!="H\.Meier@dose" END Dieses Muster würde alle Nachrichten, die auf das erste Beispiel passen, in das Brett "/XPFilter" kopieren. Eine SUCHEN-Kennung kann auch mit anderen Suchbedingungen kombiniert werden: BRETT=/XPFilter EMP=~@ SUCHEN= ( EMP="/BRETT1" || LEN>"12k" ) && ABS!="H\.Meier@dose" END Hiermit kommt die Bedingung hinzu, daß eine passende Nachricht eine öffentliche Nachricht sein muß (->S.13). Hierbei arbeitet XPFilter so, daß zuerst der SUCHEN-Ausdruck nach dem oben erklärten Schema für sich bewertet wird. Anschließend wird das Ergebnis mit allen anderen evtl. noch vorhandenen Suchbedingungen UND-verknüpft (bzw., wenn ODER (->S.12) vorhanden ist, ODER-verknüpft). Nach der getrennten Bewertung des SUCHEN-Ausdrucks wird das Ergebnis also wie das Ergebnis einer "normalen" Suchbedingung behandelt. Auf die gleiche Weise arbeitet XPFilter, wenn man mehrere SUCHEN-Kennungen in einem Muster angibt. Jede wird getrennt für sich bewertet. Anschließend wird dann das Gesamtergebnis festgestellt. 4.4 Der Aufruf Die formale Aufrufsyntax für XPFilter lautet: XPFilter [Optionen] [-uPuffer] [Musterdatei1 [Musterdatei2 [...] ] ] Dabei sollte "Puffer" beim Aufruf aus CrossPoint durch $PUFFER ersetzt werden. Bei den Musterdateien können Wildcards ('*', '?') benutzt werden. Alle Optionen bestehen aus einem Minuszeichen ('-') gefolgt von einem - 43 - Buchstaben. Bei den Buchstaben wird zwischen Groß- und Kleinschreibung *unterschieden*. Sollte eine Option noch einen Parameter benötigen, so muß dieser *direkt* - ohne trennendes Leerzeichen - auf den Buchstaben folgen. Z.B. benötigt die Option -r einen Verzeichnisnamen. Wenn das Verzeichnis "C:\XP" hieße, würde die Option so aussehen: -rC:\XP Mehrere Optionen werden durch Leerzeichen getrennt. Die Optionen, die keinen Parameter übergeben bekommen können, dürfen auch zusammen angegeben werden, z.B. -c und -i als -ci Alle Optionen lassen sich ebenfalls mit Hilfe der Umgebungsvariable XPFOPT dauerhaft einstellen. Wenn man z.B. grundsätzlich die Konfigurationsdatei (->S.51) einlesen möchte und außerdem gerne alle Pfade als relativ zum aktuellen Verzeichnis verstanden haben möchte (->S.43), kann man z.B. in der AUTOEXEC.BAT-Datei die Zeile SET XPFOPT=-n -@ einfügen. Außerdem lassen sich alle Option wieder auf ihre Standardwerte zurücksetzen, wenn man ihnen ein '!' voranstellt. Angenommen, man hat obige SET-Anweisung ausgeführt, möchte aber bei einem XPFilter-Aufruf einmal ausnahmsweise nicht die Konfigurationsdatei einlesen, kann man folgenden Aufruf nehmen: XPFILTER -!n [sonstige Optionen oder Muster] Damit gewährleistet ist, daß das Zurücksetzen ordentlich funktioniert, gibt es eine definierte Reihenfolge, in der Optionen ausgewertet werden: Zuerst wird die Konfigurationsdatei gelesen (falls gewünscht), anschließend kommen die Optionen aus XPFOPT und zum Schluß die von der Kommandozeile. Auch die Musterdateien werden in dieser Reihenfolge bearbeitet (wichtig für ABBRUCH (->S.22)). An gültigen Optionen gibt es die folgenden: -@[] XPFilter betrachtet sämtliche Dateinamen und Pfadangaben normalerweise als relativ zum Verzeichnis von CrossPoint. Das hat sich meiner Meinung nach bewährt, da die mir geschilderten Pfadprobleme deutlich abgenommen haben seit XPFilter angefangen hat, dies so zu handhaben. - 44 - Dennoch ist dieses Verhalten ungewöhnlich (üblicher Standard ist, das aktuelle Verzeichnis als Basis zu nehmen) und - besonders bei Aufrufen "per Hand" - auch desöfteren unpraktisch. Als Konsequenz kann man mit dieser Option das Basisverzeichnis entweder direkt angeben oder - wenn man das Argument wegläßt - XPFilter anweisen, das aktuelle zu nehmen. Wenn man letzteres gerne als Default hätte, empfiehlt es sich, die Option -@ in die Umgebungsvariable XPFOPT (->S.43) aufzunehmen. -a Sobald ein Muster auf eine Nachricht paßt, werden die folgenden Muster nicht mehr getestet. Es wirkt im Prinzip, als ob in allen Mustern eine ABBRUCH-Kennung (->S.22) vorhanden wäre. Mit dieser Option verhält sich die aktuelle XPFilter-Version wie die Versionen <= 1.0. -b Entfernt vom Beginn *aller* Nachrichtenbetreffe alle Textteile, die ein Reply kennzeichnen: "Re:", "Re^42:", "re: re: re:" u.ä. Da CrossPoint einen evtl. Bezug auch weiterhin durch ein '-'-Zeichen anzeigt, kann dies der Übersichtlichkeit dienen - allerdings ist das Geschmackssache... :-) -c Testet nur alle angegebenen Musterdateien auf syntaktische Korrektheit ohne etwas zu filtern. Man sollte grundsätzlich ein geändertes Musterfile einmal hiermit überprüfen lassen, um nicht erst beim Netzanruf festzustellen, daß sich ein Fehler eingeschlichen hat. Besonders interessant ist diese Funktion zusammen mit dem automatischen Bretteranlegen durch die Option -i. Es ist möglich, die Option ohne Angabe des CrossPoint- Verzeichnisses (Option -r (->S.48)) zu benutzen, allerdings fallen dann einige Tests unter den Tisch. -d Bewirkt, daß XPFilter die CrossPoint-Brettliste beim Programmstart einliest. Daraus resultieren zwei Effekte. Einmal wird bei gleichzeitiger Benutzung von -f (->S.45) das automatische DISKUSSION-IN-Setzen auf vorhandene Bretter beschränkt. In dieser Hinsicht unnötig ist die Option allerdings, wenn man bei einer ZConnect-Box pollt, die ein Programm benutzt, das in Nachrichten alle nicht bestellten - 45 - Empfangsbretter entfernt (wie z.B. Zerberus). Desweiteren macht sie z.B. im Fido keinen Sinn, da dort Nachrichten nur einen Empfänger haben können, und somit die Nachricht den Point gar nicht erreichen würde, wenn er das Brett nicht bestellt hätte... Die zweite Auswirkung dieser Option betrifft Variablen (->S.53). Sie bestimmt, wie diese auf EMP-Headerzeilen "reagieren". Dazu später mehr (->S.55). Der Nachteil des Einlesens der Brettliste besteht in der Notwendigkeit, die Liste ständig im Speicher zu halten. Das verbraucht bei großen Brettlisten u.U. relativ viel RAM. -e[] Diese Option weist XPFilter an, bei einem evtl. Fehler zu warten, anstatt sofort zu CrossPoint zurückzukehren. Wenn der Option eine Zahl als Parameter angefügt wird (z.B. "-e123" ), so gibt diese die Zeit in Sekunden an, die gewartet wird. Wird die Zeitangabe weggelassen, hält XPFilter so lange bis eine Taste gedrückt wird. -f Setzt DISKUSSION-IN beim Kopieren/Verschieben nur auf den ersten der ursprünglichen Empfänger bzw. bei Kombination mit der Option -d (->S.44) auf den ersten ursprünglichen Empfänger, der in der Brettliste vorhanden ist, -g Diese Option verändert die Arbeitsweise der BODY-/BODY-I- Suche (->S.18) dahingehend, daß Signaturen in Nachrichtentexten nicht mehr mitdurchsucht werden. Allerdings gibt es keinen Standard, um Signaturen zu erkennen, so daß XPFilter sich da auf ein recht verbreitetes Merkmal beschränkt: Alles, was nach einer Zeile, die entweder nur "--" oder nur "-- " enthält, folgt, wird bei Benutzung dieser Option nicht mehr beachtet. Bei eigenen Signaturen sollte man übrigens auch darauf achten, daß sie mit diesem Merkmal beginnen, da auch andere Programme damit arbeiten. Etwas anders verhält sich die Option im Fido. Dort wird nicht eine evtl. vorhandene Signatur von der Suche ausgeschlossen, sondern nur die "Origin"-Zeile, die in allen Nachrichten enthalten ist. -h Wenn XPFilter, mehr oder weniger eigenständig, einen Text in eine Nachricht einfügt (z.B. bei GRUND (->S.28)), so wird diesem normalerweise das von CrossPoint übernommene "##" - 46 - vorangestellt. Soll stattdessen ein anderer Zeilenanfang benutzt werden, so kann der mit dieser Option angegeben werden. Denkbar wäre z.B. : -h> Dadurch würden, aufgrund von CrossPoints Quotefärbung, die entsprechenden Zeilen farblich hervorgehoben erscheinen. -i Diese Option dient zum automatischen Anlegen der Filterbretter. XPFilter liest dafür zuerst die Brettliste von CrossPoint ein und erzeugt für jedes BRETT (->S.25), das | noch nicht vorhanden ist, eine neue Nachricht. Diese wird | entweder mit in den gefilterten Puffer geschrieben (an den | Beginn oder direkt vor die erste Nachricht, die in dieses | Brett geht) oder, beim reinen Check der Muster mit -c | (->S.44), ins AUTOEXEC-Verzeichnis. Dieses muß dann | anschließend abgearbeitet werden (näheres siehe CrossPoint- | Dokumentation). | | *Achtung*: Falls mit dieser Option Bretter während des | Filterns angelegt werden sollen, darf sich die Reihenfolge | der Nachrichten im Puffer nach der Bearbeitung durch | XPFilter nicht mehr verändern, d.h. man sollte ihn z.B. | nicht anschließend noch sortieren lassen... Durch diese Option ist es nicht mehr notwendig, die Filterbretter per Hand anzulegen, wie es ansonsten der Fall wäre, um XP davon abzuhalten, Crosspostings ohne existierenden Empfänger im "/Junk"-Brett zu plazieren. *Tip*: Besonders praktisch ist es, wenn man über das Zusatzmenu von CrossPoint eine Batchdatei aufrufen läßt, die zuerst einen Editor mit der eigenen Musterdatei lädt und anschließend - nachdem man den Editor wieder verlassen hat - XPFilter mit den Optionen -c und -i startet. Dabei sollte bei der Konfiguration des Menupunktes der Schalter "AUTOEXEC-Verzeichnis bearbeiten" eingeschaltet werden, um die Bretter sofort anlegen zu lassen. -j XPFilter versucht normalerweise, aus der ROT-Headerzeile der ersten Nachricht auf den Server zu schließen, von dem der Puffer stammt. Diese Information wird bei von XPFilter erstellten Nachrichten (z.B. Berichten) benutzt, um deren Absender zu generieren. - 47 - Sollte dies - aus welchen Gründen auch immer - nicht funktionieren, so läßt sich mit dieser Aufrufoption eine beliebige Domain angeben, die stattdessen benutzt wird. -k[] Beläßt den Originalpuffer *unverändert*, d.h. sämtliche Aktionen, die den Puffer normalerweise modifizieren würden, haben auf ihn keinen Effekt. Stattdessen wird, falls eine Datei angegeben worden ist, der gefilterte Puffer unter diesem Namen abgelegt. Fehlt der Dateiname, wird er einfach wieder gelöscht. Die Bearbeitung von EXPORT, BATCH, SENDEN u.ä. erfolgt in jedem Fall wie gewohnt. -l[][:Datei] Erstellt nach Bearbeitung des Puffer einen Bericht mit Statistiken über die getätigten Aktionen, die Größe des Puffers und anderem. Der Bericht erscheint standardmäßig im Brett "/Netzanruf", allerdings kann ein anderes Brett als Parameter angegeben werden (z.B. "-l/Berichte") Zusätzlich besteht die Möglichkeit, diesen Bericht in einen externen Puffer zu schreiben, indem ein Dateiname (durch einen Doppelpunkt abgetrennt) angegeben wird. Vorhandene Dateien werden dabei ergänzt, nicht überschrieben. Innerhalb des Dateinamens läßt sich dieselbe '$'-Numerierung wie bei EXPORT (->S.27) verwenden. Außerdem kann statt des Datei- auch ein Verzeichnisname spezifiziert werden, wobei XPFilter dann in diesem Verzeichnis ein File mit eindeutigem, auf ".zer" endendem Namen erzeugt. Dies dient vor allem der Möglichkeit, den Puffer direkt in CrossPoints AUTOEXEC-Verzeichnis abzulegen. -m Es gab in der Vergangenheit in seltenen Fällen Probleme mit einem zu großen Speicherverbrauch von XPFilter. Dies trat insbesondere bei zu großen Musterdateien auf, wie sie z.B. leicht beim Einsatz von XPKilt ohne Sammelmuster (siehe beiliegende FAQ) oder beim Aufruf aus anderen Programmen als CrossPoint entstehen. Um das Problem einzuschränken, existiert dieser Schalter. Er verringert den für ein Muster benötigten Speicher. Aber wie immer in solchen Fällen, zieht dieses einen gravierenden Nachteil mit sich: Die Geschwindigkeit reduziert sich je nach Leistung des Rechners und Anzahl der Muster u.U. *drastisch*. :-( - 48 - -n[] Hiermit kann der Name einer Konfigurationsdatei (->S.51) angegeben werden, mit deren Hilfe alle Kommandozeilenparameter ebenfalls eingestellt werden können. Liegt die Datei nicht im selben Verzeichnis wie XPFILTER.EXE muß der gesamte Pfad mitangegeben werden. Gibt man keinen Dateinamen an, wird die Datei XPFILTER.CFG genommen. Möchte man die Konfigurationsdatei grundsätzlich einlesen, empfiehlt es sich, die Option -n in die Umgebungsvariable XPFOPT (->S.43) aufzunehmen. -o Läßt XPFilter während des Filterns zu jeder Nachricht, auf die ein Muster gepaßt hat, eine kurze Übersicht mit den getätigten Aktionen, Absender, Empfänger, Betreff, MsgID sowie den auslösenden Suchbedingungen ausgeben. Wenn nur ausgewählte Muster in dem Bericht erscheinen sollen, ist dies mit der Option -w (->S.50) im Zusammenspiel mit der Kennung AUSGABE (->S.24) möglich. -p Ähnlich wie die Option -o, allerdings wird hierbei vor jeder neuen Ausgabe der Bildschirm gelöscht, um die Optik zu verbessern... :-) -q Bewirkt, daß XPFilter alle unnötigen Ausgaben (z.B. die Nachrichtenzählung) unterdrückt, und nur noch Fehlermeldungen und ggf. durch die Option -o hervorgerufenes auf die Standardausgabe schreibt. Damit kann die Ausgabe von XPFilter in eine Datei umgelenkt und somit gesichert werden. -r Benötigt als Parameter den Namen des CrossPoint- Verzeichnisses (z.B. "-rC:\XP"). Der Name des Verzeichnisses muß XPFilter auf jeden Fall mitgeteilt werden, wenn sich CrossPoint nicht mittels des DOS-PATH lokalisieren läßt. Das kann wahlweise über diese Option, über eine Konfigurationsdatei (->S.51) oder über die DOS- Umgebungsvariable XPDIR (mit Hilfe des DOS-Befehls SET, z.B. "SET XPDIR=C:\XP") geschehen. -s Hiermit kann der für alle SENDEN-Aktionen (->S.37) benutzte Server angegeben werden (z.B. -sMYBOX). Fehlt diese Option, so nimmt CrossPoint den Server, der für den jeweiligen User eingetragen ist bzw. - falls der User noch nicht im Adressbuch steht - die Stammbox. Mit Hilfe der Kennung SERVER (->S.38) läßt sich dies auch einzeln auf Musterbasis angeben, so daß je nach Muster ein - 49 - anderer Server benutzt werden kann. -t[] Diese Option dient zur Angabe eines Verzeichnisses, in dem XPFilter Temporärdateien anlegen soll. Wenn kein Pfad spezifiziert wird, wertet XPFilter die Inhalte der Umgebungsvariablen TMP und TEMP (in dieser Reihenfolge) aus. Falls die Option gar nicht benutzt wird, werden alle Temporärdateien im selben Verzeichnis angelegt, in dem sich auch der zu filternde Puffer befindet. Zwei Hinweise zu dieser Option: Man sollte sich gründlich überlegen, ob man aus Geschwindigkeitsgründen eine RAM-Disk angibt. Diese kann u.U. leicht zu klein sein, um den ganzen, evtl. noch durch Aktionen vergrößerten Puffer sowie diverse andere Dinge aufzunehmen (es sei denn, man benutzt eine *swapbare* RAM-Disk wie etwa SVDisk (für OS/2) - Dank an Hans-Joachim Zierke (hajo@quijote.in-berlin.de) für den Tip!). Zweitens ist zu beachteten, daß unabhängig von der Lage des Temporärpfades auf jeden Fall in dem Verzeichnis, in dem sich der Puffer befindet, noch genügend Platz sein muß, um den neuen Puffer *zusätzlich* zum alten aufzunehmen. XPFilter kopiert aus Sicherheitgründen den neuen Puffer zuerst dorthin, bevor der alte gelöscht wird. Alles andere würde bei einem Lese-/Schreibfehler arge Probleme auslösen... -u Diese Option gibt den Namen des zu filternden Puffers an. Bei einem Aufruf direkt aus dem Feld "Eingangsfilter" wird der Name i.d.R. $PUFFER lauten und dadurch von CrossPoint automatisch eingesetzt: -u$PUFFER Solange nicht die Option -c (->S.44) benutzt wird, ist die Angabe eines Puffers zwingend erforderlich. -v[][:Datei] Bewirkt die Ausgabe derselben Daten wie bei der Option -o. Allerdings geht die Ausgabe nicht auf den Bildschirm, sondern in eine neu erstellte Nachricht, die anschließend im Brett /Netzanruf erscheint. Wahlweise kann auch ein anderer Brettname als Parameter mit angegeben werden (z.B. "-v/Bericht"). Diese Nachrichten können leicht sehr groß werden... Zusätzlich besteht die Möglichkeit, diesen Bericht in einen - 50 - externen Puffer zu schreiben, indem ein Dateiname (durch einen Doppelpunkt abgetrennt) angegeben wird. Vorhandene Dateien werden dabei ergänzt, nicht überschrieben. Innerhalb des Dateinamens läßt sich dieselbe '$'-Numerierung wie bei EXPORT (->S.27) verwenden. Außerdem kann statt des Datei- auch ein Verzeichnisname spezifiziert werden, wobei XPFilter dann in diesem Verzeichnis ein File mit eindeutigem, auf ".zer" endendem Namen erzeugt. Dies dient vor allem der Möglichkeit, den Puffer direkt in CrossPoints AUTOEXEC-Verzeichnis abzulegen. -w Wenn diese Option angegeben wird, werden nur die Muster in die Ausgabe der Optionen -o, -p, -v aufgenommen, die die Kennung AUSGABE (->S.24) enthalten. Das kann insbesondere dazu dienen, den von -v erzeugten "Ausführlichen Bericht" auf die wesentlichen Muster zu beschränken. -x Normalerweise werden beim Filtern alle entfernten EMP- Headerzeilen in KOP gewandelt. Das kann mit dieser Option unterbunden werden, die alten Zeilen werden dann ersatzlos gelöscht. Ähnliches kann mit N-HEADER=~KOP auf Musterbasis erreicht werden (->S.33). -y Wenn ein Muster mit MARKIEREN (->S.30) oder mit BEZIEHEN (->S.25) auf eine Nachricht paßt, so ist diese in der Regel, aus welchen Gründen auch immer, recht wichtig. Dessen ungeachtet kann es aber passieren, daß ein anderes Muster sie aufgrund von LOESCHEN (->S.29) aus dem Puffer entfernt. Dies kann mit dieser Option verhindert werden. Eine solche Nachricht kann dann zwar noch verschoben oder kopiert, aber nicht mehr gelöscht werden. Sollte sie nach Bearbeitung aller Muster normalerweise keinen Empfänger mehr haben, so werden die usprüglichen Empfänger wieder eingesetzt. Zusätzlich fügt XPFilter dann eine kurze Meldung am Nachrichtenanfang ein. Diese Option wirkt global auf alle Muster. Im Gegensatz dazu läßt sich ein ähnlicher Effekt mit der Kennung ERHALTEN (->S.27) auf Musterbasis erreichen. -z Für die Suchkennungen QUOTE-ANTEIL (->S.20) und QUOTE-ZEILEN (->S.20) ist es nötig, irgendwie die Zeilen zu erkennen, die gequotet sind. Da es dafür keinen Standard gibt, ist das leider nicht mit 100%-iger Sicherheit möglich. - 51 - Standardmäßig betrachtet XPFilter alle Zeilen, die auf den folgenden Regulären Ausdruck (->S.73) passen, als Quotezeilen: ^ *.?.?.?[>|:] Aber mit Hilfe der Option -z läßt sich auch ein beliebiger anderer Ausdruck angeben, der stattdessen benutzt werden soll. 4.5 Konfigurationsdatei Es lassen sich mit Hilfe der Aufrufoptionen viele Dinge einstellen. Da es aber etwas lästig sein kann, diese bei jedem Start XPFilter zu übergeben - insbesondere wenn man für mehrere Boxen die gleichen Optionen benutzt - lassen sich alle Option auch innerhalb einer Konfigurationsdatei angeben. Diese heißt standardmäßig XPFILTER.CFG und wird mit der Option -n aktiviert. Allerdings kann man -n auch einen anderen Dateinamen als Parameter mitgeben: XPFILTER -n -uPuffer [Musterdatei(en)] Dabei ist zu beachten, daß, wenn die Konfigurationsdatei nicht im selben Verzeichnis wie XPFILTER.EXE steht, der volle Pfad mitangegeben werden muß. Eine Konfigurationsdatei hat im Wesentlichen denselben Aufbau wie eine Musterdatei. Jede Zeile beginnt mit einer Kennung. Falls eine Kennung einen Parameter benötigt, wird dieser nach einem '='-Zeichen angefügt. So eine Datei könnte z.B. folgendermaßen aussehen: VERBOSEMAIL LOG ERROR PATTERN=general.xpf XPDIR=c:\xp Ein ausführlicheres Beispiel, das sich leicht anpassen läßt, findet sich in der Datei XPFILTER.CFG. Bis auf eine Ausnahme entspricht jede der innerhalb der Konfigurationsdatei möglichen Kennungen einer Aufrufoption. Die benötigten Parameter sind ebenfalls identisch. Die Ausnahme ist die Kennung "PATTERN". Sie kann mehrmals angegeben werden und gibt jeweils eine Musterdatei an. Auf der Kommandozeile können - 52 - wahlweise weitere Musterdateien angegeben werden. *Tip*: Wenn man bei mehreren Boxen Netzanrufe tätigt, kann man sich eine Musterdatei erstellen mit Mustern, die für alle Boxen gelten. Diese wird dann z.B. über die gemeinsame Konfigurationsdatei angegeben. Die restlichen, für jede Box unterschiedlichen Musterdateien, können dann über die Kommandozeile zusätzlich übergeben werden. Es folgt eine Liste der möglichen Kennungen zusammen mit den zugehörigen Aufrufoptionen. Eine nähere Erläuterung findet sich bei der Auflistung der Optionen (->S.42). Kennung Wirkung s.Option ABORT Abbruch bei passendem Muster -a CHECK Nur Test der Musterdateien -c CHECKDISC DISKUSSION-IN nur auf vorhand. Bretter -d DELRE "Re:" von allen Betreffen entfernen -b DOMAIN Absenderdomain für erstellte Nachrichten -j ERROR Bei Fehler warten -e FOLLOWUP DISKUSSION-IN nur auf einen EMP setzen -f IGNORESIG Signaturen nicht durchsuchen -g INIT Bretter anlegen -i KEEP Puffer nicht verändern -k KEEPMAILS MARKIEREN/BEZIEHEN Nachr. nicht löschen -y LOG Bericht erstellen -l NOKOP Keine neuen KOP erstellen -x PREFIX Änderung von XPFilters Zeilenprefix -h QUIET Keine Bildschirmausgaben -q QUOTE Regulärer Ausdruck für Quotekennungen -z SAVEMEM Speichersparmodus -m SELECTOUTPUT Nur Muster mit AUSGABE ausgeben :) -w SERVER Server für SENDEN -s TMPDIR Verzeichnis für Temporärdateien -t VERBOSE Ausgabe der bearbeiteten Nachrichten -o VERBOSEMAIL dito, in eine neue Nachricht -v VERBOSESCREEN dito, mit Löschen des Bildschirms -p WORKDIR Arbeitsverzeichnis -@ XPDIR Angabe des CrossPoint-Verzeichnisses -r 4.6 Die XPFILTER.DEF Datei Ein Großteil der offiziellen ZConnect-Kennungen läßt sich bereits standardmäßig mit den Suchbedingungen abfragen (->S.11). Allerdings kommt es häufig vor, daß weitere Kennungen benötigt werden, wobei es sich sowohl um neu in den Standard aufgenommene als auch um "inoffizielle" Kennungen handeln kann. - 53 - Da XPFilter aus naheliegenden Gründen nie alle kennen können wird, gibt es eine Möglichkeit, alle zusätzlich zu den "festverdrahteten" benötigten Kennungen dem Programm mitzuteilen. Dazu dient eine Datei names XPFILTER.DEF. Sie muß im selben Verzeichnis wie XPFILTER.EXE stehen, und wird, falls sie dort zu finden ist, am Programmstart eingelesen. In ihr kann pro Zeile eine Kennung stehen, wobei die Groß-/Kleinschreibung ohne Belang ist. Leerzeilen sowie Zeilen, die mit einem Semikolon oder einer Raute ('#') beginnen, werden nicht beachtet. Bei der Definition neuer Kennungen wird zwischen zwei Typen unterschieden: Denjenigen, die beliebig oft in einem Header vorkommen dürfen und denen, die max. einmal erlaubt sind. Letztere müssen durch ein angehängtes ":1" kenntlich gemacht werden. Diese Information benötigt XPFilter vor allem für N-HEADER (->S.33). Ein Beispiel: # Diese Datei definiert neue Suchkennungen u-sender:1 u-keywords Damit werden die zwei Kennungen "u-sender" und "u-keywords" definiert, die von manchen Gates oder auch von CrossPoint in den Nachrichtenheader eingefügt werden. Sobald diese Kennungen so in der XPFILTER.DEF-Datei definiert worden sind, können sie in Suchbedingungen benutzt werden. Z.B. wäre jetzt in einem Muster folgende Zeile möglich: U-KEYWORDS=xpfilter 4.7 Variablen Es gibt Anwendungen, bei denen es nützlich wäre, wenn man auf Inhalte von Headerzeilen zugreifen könnte. Dies ginge zwar zu einem gewissen Grad mit Batchdateien, die exportierte Nachrichten entsprechend auswerten, aber dieses hätte neben dem nicht gerade geringen Aufwand den Nachteil, daß die so ermittelten Inhalte nicht wieder bei Aktionen in XPFilter verwendet werden könnten. Außerdem ist der Zugriff auf die Headerinhalte ja bereits integraler Bestandteil von XPFilter, so daß es eigentlich doppelte Arbeit wäre, per externem Programm erneut die Header auswerten zu lassen. - 54 - Aus diesen Gründen gibt es Variablen. Sie werden wahrscheinlich von vielen Benutzern erstmal gar nicht benötigt werden, aber sie bieten fortgeschrittenen "Mustererstellern" viele zusätzliche Möglichkeiten. 4.7.1 Grundlegendes Wie benutzt man diese Variablen? Nun, XPFilter kann in jedem Muster maximal 10 verschiedene Variablen verwalten. Jeder von ihnen kann der Inhalt einer Headerzeile zugewiesen werden, indem man die Kennungen VAR0, VAR1, VAR2, ..., VAR9 benutzt: VAR0=ABS VAR1=EMP VAR5=MID Nimmt man diese drei Zeilen in ein Muster auf, so bekommt, wenn eine Nachricht auf die Suchbedingungen (->S.11) des Musters gepaßt hat, die Variable 0 den Inhalt der ABS-Headerzeile zugewiesen, die Variable 1 den von EMP und die Variable 5 erhält die Message-ID aus der MID-Zeile. Diese Inhalte der Variablen lassen sich anschließend in bestimmten Aktionen des Musters benutzen, indem sie durch die Zeichenkombinationen $0, $1, $2, ..., $9 angesprochen werden. Dies funktioniert bei den Aktionen BATCH (->S.24), BRETT (->S.25), N- ANTWORT-AN (->S.32), N-DISKUSSION-IN (->S.32), N-HEADER (->S.33), N- STICHWORT (->S.34), SENDEN (->S.37), SERVER (->S.38), TEXT (->S.40), TITEL (->S.39) und ZIEL (->S.40). Belegt man also z.B. wie oben beschrieben die Variable 5 mit der MID, so bewirkt die Musterzeile TEXT=Die Msg-ID dieser Nachricht lautet: <$5> daß an den Beginn jeder Nachricht eben dieser Text erscheint, wobei XPFilter "$5" durch den Inhalt der Variablen 5 - in diesem Fall die MID - ersetzt. Soll bei den Aktionen die Zeichenfolge "$5" selber benutzt werden, ohne daß sie durch den entsprechenden Variableninhalt ersetzt wird, so muß ein '\' davorgesetzt werden. Bei TEXT=Dies ist keine Variable: \$5 erscheint am Beginn aller passenden Nachrichten: Dies ist keine Variable: $5 - 55 - Um auch das '\' selber erreichen zu können, muß ein weiteres '\' vorrangestellt werden: Aus "ab\\cd" wird "ab\cd". 4.7.2 Einfache Variablenzuweisung Die bisher beschriebene Möglichkeit, den Inhalt einer Variablen zu bestimmen, stellt nur die einfachste Möglichkeit dar. Aber bevor Weiteres gezeigt wird, noch ein paar Erläuterungen dazu. Als Kennungen, die den Inhalt der ihnen entsprechenden Headerzeile einer Variablen zuweisen, sind alle erlaubt, die auch in Suchbedingungen (->S.11) möglich sind, einschließlich der in einer evtl. vorhandenen XPFILTER.DEF-Datei (->S.52) definierten. Auch XPFilters numerische Kennungen wie z.B. GRUPPEN (->S.19) oder QUOTE- ANTEIL (->S.20) können benutzt werden. Sie enthalten jeweils den zu einer Nachricht gehörenden Wert. Eine Ausnahme ist die Kennung BODY (->S.18), die nicht benutzbar ist. BODY-I dagegen kann verwendet werden und bezieht sich bei dieser Art der Zuweisung immer auf die erste Zeile im Nachrichtentext (->S.56) Ebenso beziehen sich die anderen Kennungen immer auf die erste im Header stehende Headerzeile, d.h. wenn eine Kennung mehrmals im Header auftaucht, wird grundsätzlich der Inhalt der ersten der Variablen zugewiesen. Aber auch hierbei existiert eine wichtige Ausnahme: Wird die Aufrufoption -d (->S.44) bzw. ihr Äquivalent in der Konfigurationsdatei, die Kennung CHECKDISC, benutzt, liest XPFilter wie beschrieben beim Programmstart die CrossPoint-Brettliste ein. Damit kann XPFilter feststellen, welche Empfängerbretter einer Nachricht vorhanden sind, und es nutzt diese Möglichkeit, indem Variablenzuweisungen, die EMP-Headerzeilen betreffen, nur diese bereits vorhandenen Bretter beachten. Die nicht vorhandenen Bretter werden dann bei den Variablenzuweisungen schlicht übergangen, als ob sie gar nicht im Nachrichtenheader stehen würden. Dies ermöglicht interessante Anwendungen, wie später bei den Beispielen (->S.65) gezeigt wird. Nichtöffentliche EMPs sind davon nicht betroffen und werden immer ganz "normal" behandelt. Sollte eine bei einer Zuweisung benutzte Headerzeile in einer Nachricht nicht vorhanden sein, so wird der Inhalt der entsprechenden Variable auf eine leere Zeichenkette ("") gesetzt. - 56 - 4.7.3 Variablenzuweisung mit Regulären Ausdrücken Im Gegensatz zu den mit den bisherigen Erläuterungen möglichen Zuweisungen ist es oftmals wünschenswert, nur einen Teil des Inhalts einer Headerzeile der entsprechenden Variable zuzuweisen. Bei der Überlegung, wie das zu realisieren sein könnte, drängen sich die Regulären Ausdrücke (->S.73) wieder mal gerade zu auf. :-) Daher läßt sich neben der einfachen Zuweisung auch noch zusätzlich, durch einen Doppelpunkt abgetrennt, ein Regulärer Ausdruck bei den VAR0- bis VAR9-Kennungen angegeben. Beispiel: VAR5=ABS:^[^ ]* Damit erhält die Variable 5 nur den Anfang des Absenders bis zum ersten Leerzeichen. Dadurch würde z.B. ein evtl. in Klammern dahinter stehender Realname nicht mehr erfaßt und man hätte die reine Adresse isoliert. Im Unterschied zu der Zuweisung ohne Ausdruck werden hierbei allerdings bei mehrfach vorkommenden Headerzeilen ggf. auch die weiteren beachtet. XPFilter nimmt immer den Inhalt der ersten Headerzeile, auf die der Ausdruck paßt. Ebenso wird bei BODY-I die erste Textzeile genommen, auf die der Ausdruck paßt. Allerdings werden bei Benutzung der Option -d (bzw. CHECKDISC) auch hierbei, wie oben beschrieben, nur existierende EMPs beachtet. Aber die Möglichkeiten gehen noch weiter. Würde man z.B. auf ähnliche Weise wie im vorhergehenden Beispiel nur den Domainanteil der Adresse isolieren wollen, gäbe es Probleme, da z.B. VAR5=ABS:@[^ ]* diesen zwar ermittelt, aber das '@' immer ebenfalls davor läßt. Bei einer ABS-Zeile wie ABS: smith@some.where.com (John Smith) enthielte die Variable 5 anschließend nicht die reine Domain, sondern @some.where.com Aus diesem Grund läßt sich noch zusätzlich zu Kennung und Regulärem Ausdruck eine Nummer angeben, die, wieder durch einen Doppelpunkt getrennt, dazwischen gesetzt werden kann. Sie bezeichnet die Nummer eines im Ausdruck stehenden Klammernpaares und - 57 - weist der Variablen nur den auf den Inhalt der Klammer passenden Text zu. Obiges Problem ließe sich damit mit folgender Variablenzuweisung lösen: VAR5=ABS:1:@([^ ]*) Ergebnis: Die Variable bekommt einen Inhalt, sobald der *gesamte* Ausdruck auf die ABS-Zeile paßt. Dieser Inhalt aber stellt nur den Teil des Absenders dar, der auf die erste Klammer gepaßt hat. Entsprechend wäre bei der beschriebenen ABS-Zeile der Inhalt der Variablen 5 anschließend: some.where.com Zur Angabe der Nummer einer Klammer können die Ziffern von 1 bis max. 5 benutzt werden. Dabei zählen nur die Klammern, die auch als Steuerzeichen benutzt werden, nicht die, die durch ein '\' davor von ihrer Steuerzeichenfunktion "befreit" worden sind (->S.73). Falls z.B. der Realname benötigt wird, aber die normalerweise in einer ABS-Zeile darum herumstehenden Klammern stören, bewährt sich folgende Variablenzuweisung: VAR5=ABS:1:\((.*)\) Wieder obige ABS-Zeile als Beispiel genommen, hätte die Variable 5 anschließend den Inhalt John Smith Zu beachten wäre noch, daß die bei Suchbedingungen möglichen Einschränkungen (->S.60) bei Variablen nicht benutzbar sind. 4.7.4 Variablen und BATCH Wenn Variablen in einer BATCH-Aktion (->S.24) benutzt werden, gibt es einige Besonderheiten und erweiterte Möglichkeiten. Zuerst einmal lassen sich die Variablen natürlich ganz "normal" benutzen, wie bisher beschrieben: BATCH=test.bat $0 $1 $2 Damit werden der Bachdatei die Inhalte der Variablen als Parameter übergeben. Aber da die Parameterübergabe nicht gerade eine starke Seite von DOS darstellt (hat DOS eigentlich welche? :->), bietet XPFilter noch eine andere Möglichkeit. - 58 - Bei jedem BATCH-Aufruf werden automatisch für alle Variablen, die einen Inhalt zugewiesen bekommen haben, Umgebungsvariablen angelegt. Diese haben die Namen XPF0, XPF1, XPF2, ..., XPF9. Sie lassen sich z.B. in einer Batchdatei, wie alle anderen Umgebungsvariablen auch, mit Hilfe von %% ansprechen. Folgende Batchdatei würde z.B. einfach den Inhalt der ersten drei Variablen ausgeben: @echo off echo %XPF0% echo %XPF1% echo %XPF2% Hieße diese Datei "test.bat" und lautete ein Muster EMP=. VAR0=ABS VAR1=ABS:^[^ ]* VAR2=ABS:1:\((.*)\) BATCH=test.bat END so würde zu jeder Nachricht im Puffer der gesamte Absender, die Adresse sowie der Realname ausgegeben. (Nicht sonderlich spektakulär, aber es dient ja auch nur als Beispiel... :-) Die Zahl der Zeichen, die aus einer Variable in die zugehörige Umgebungsvariable übernommen wird, ist auf 120 beschränkt. Soweit funktioniert schonmal die Variablenübergabe in die eine Richtung, d.h. von XPFilter an die aufgerufene Batch- oder Programmdatei. Aber es geht auch andersrum, d.h. eine Batchdatei kann Einfluß auf die Variableninhalte innerhalb von XPFilter nehmen. Da dies nicht durch einfache Änderungen der Inhalte der Umgebungsvariablen möglich ist, ist dafür allerdings leider ein etwas umständlicherer Weg nötig. Direkt nach jeder BATCH-Ausführung sucht XPFilter im *CrossPoint- Verzeichnis* nach einer Datei namens XPFILTER.VAR. In ihr können die neuen Variableninhalte angegeben werden. Dazu muß sie aus Zeilen bestehen, die mit der entsprechenden Variablennummer beginnen, gefolgt von einem '=' und dem neuen Variableninhalt. Zeilen, die mit ';' oder '#' beginnen sowie Leerzeilen werden nicht beachtet. Beispiel: - 59 - ; Diese Zeile ist ohne tieferen Sinn... :-) 1=Diesen Text bekommt Variable 1 5=Und etwas für Variable 5 0=Und auch Variable 0 soll nicht leer ausgehen Damit bekommen die Variablen 0, 1 und 5 die entsprechenden Inhalte. Alle nicht in der Datei aufgeführten Variablen bleiben unverändert. Das Format einer Zeile ist in der XPFILTER.VAR-Datei etwas strenger als bei anderen, ähnlich aufgebauten, XPFilter-Dateien. Zwischen der Ziffer und dem '=' dürfen keine Leerzeichen stehen. Dafür werden Leerzeichen, die nach dem Gleichheitszeichen stehen, mit in die Variable übernommen. Alle so veränderten Variablen können anschließend in den anderen, die Verwendung von Variablen erlaubenden Aktionen benutzt werden, da diese allesamt nach BATCH ausgeführt werden (->S.63). Nachdem die XPFILTER.VAR-Datei eingelesen worden ist, wird sie direkt wieder gelöscht, damit nachfolgende Muster nicht beeinflusst werden. Zu beachten wäre noch, daß eine evtl. vorhandene XPFILTER.VAR-Datei nach BATCH nur eingelesen wird, wenn im selben Muster auch mind. eine Variablendefintion (VARx) vorhanden ist. 4.7.5 Probleme Variablen sollten generell mit Vorsicht benutzt werden, insbesondere wenn die Variableninhalte in Aktionen wie BRETT oder ZIEL eingesetzt werden. XPFilter hat nur äußerst geringe Kontrollmöglichkeiten, ob die so entstandene Zeichenkette korrekt und vor allem sinnvoll ist. Fast der einzige Punkt, bei dem XPFilter eingreift, ist der Fall, daß eine BRETT- (und u.U. auch eine ZIEL-) Aktion nach der Variableneinsetzung gar keinen Inhalt mehr hat. In diesem Fall gibt XPFilter eine Warnung aus und setzt das Brett "/Junk" ein. Generell ist aber jeder selbst dafür verantwortlich, daß die Variablen vernünftige Inhalte bekommen... Außerdem ergibt sich bei BRETT das Problem, daß das automatische Bretteranlegen mit der Option -i (->S.46) nicht funktioniert, wenn die Muster mit der Option -c (->S.44) überprüft werden. Aufgrund der zur Zeit leider nur mangelhaft implementierten Zukunftsvorhersagefähigkeit(TM) von XPFilter, "weiß" es natürlich zu diesem Zeitpunkt nicht, welchen Inhalt eine Variable und damit die BRETT- - 60 - Kennung später einmal haben wird. | Wird -i dagegen beim eigentlichen Filtern angegeben, funktioniert dann | auch das Anlegen dieser Bretter. 4.8 Einschränken von Suchbedingungen Die bisher beschriebenen Möglichkeiten zur Formulierung von Suchbedingungen beschränkten sich auf Reguläre Ausdrücke, mit denen wohl der weitaus größte Teil der gewünschten Abfragen erledigt werden kann. Aber XFPilter kann noch mehr. :-) Es lassen sich nämlich zusätzlich noch einschränkende Häufigkeits- und/oder Bereichsangaben machen. 4.8.1 Häufigkeiten So lassen sich z.B. Häufigkeitswünsche der Art "In dem Nachrichtentext soll in fünf bis sieben Zeilen der Text 'The Simpsons' vorkommen" folgendermaßen formulieren: BODY-I=H5-7:The Simpsons Diese Bedingung paßt genau dann, wenn fünf, sechs oder sieben Zeilen den Text enthalten, sonst nicht. Ähnlich lassen sich Bedingungen wie "in mehr als fünf Zeilen", "in weniger als drei Zeilen" und "in genau zehn Zeilen" ausdrücken: BODY-I=H>5:The Simpsons bzw. BODY-I=H<3:The Simpsons bzw. BODY-I=H10:The Simpsons *Achtung*: Die Bedingung "in weniger als x Zeilen" schließt den Fall ein, daß der Text gar nicht vorkommt! Auch die Negation mittels '~' (->S.73) funktioniert: BODY-I=H5-7:~The Simpsons Dies passt, wenn fünf, sechs oder sieben Zeilen *nicht* "The Simpsons" - 61 - enthalten. Außer BODY-I lassen sich auch alle anderen nicht-numerischen Suchkennungen benutzen, z.B.: EMP=H>2:/comp/os/linux Das paßt, wenn eine Nachricht mehr als zwei Empfänger aus der "/comp/os/linux/*"-Hierarchie besitzt. Der zu suchende "Text" ist natürlich wie bei allen anderen Suchbedingungen wieder kein "echter" Text, sondern ein Regulärer Ausdruck (->S.73). 4.8.2 Bereiche Die zweite Möglichkeit der Einschränkung von Suchbedingungen stellen Bereiche dar. Diese entsprechen Sätzen der Art "In dem Nachrichtentext soll in den Zeilen fünf bis sieben der Text 'The Simpsons' vorkommen" (man beachte den feinen Unterschied in der Formulierung im Vergleich zu den Häufigkeitsangaben (->S.60) ! :-). Die Syntax ist bis auf ein 'Z' statt des 'H's identisch zu der im vorherigen Abschnitt beschriebenen: BODY-I=Z5-7:The Simpsons Die Bedingung paßt, wenn in den Zeilen fünf, sechs oder sieben mind. einmal "The Simpsons" auftaucht. Entsprechend ist die Formulierung für "nach Zeile fünf" bzw. "vor Zeile drei" bzw. "in Zeile zehn": BODY-I=Z>5:The Simpsons bzw. BODY-I=Z<3:The Simpsons bzw. BODY-I=Z10:The Simpsons Und die Negation: BODY-I=Z5-7:~The Simpsons - 62 - Bedeutung: In Zeile fünf, sechs und sieben darf *nicht* "The Simpsons" stehen. Auch die Bereiche lassen sich mit allen anderen nicht-numerischen Suchkennungen verwenden - auch wenn das bei allen Headerkennungen wenig Sinn macht, da dort die Reihenfolge nicht definiert ist. Für das Verständnis der Bereiche - und insbesondere der im folgenden beschriebenen Kombination mit Häufigkeitsangaben - ist es vielleicht nützlich zu wissen, wie XPFilter sie intern bearbeitet: Alle außerhalb eines Bereiches liegenden Zeilen werden schlicht ignoriert als seien sie nicht vorhanden. Damit erscheint die Nachricht für diese Bedingung so als bestünde sie überhaupt nur aus diesen Zeilen, und der Reguläre Ausdruck sowie eine evtl. Häufigkeitsangabe wird dementsprechend auch nur auf diese Zeilen bezogen. Es wird praktisch nur eine "Mini-Ausgabe" der Nachricht bearbeitet, die aber auf völlig herkömmliche Weise. 4.8.3 Kombinierte Häufigkeits-/Bereichsangaben Die beiden in den vorherigen Abschnitten beschriebenen Einschränkungsmöglichkeiten lassen sich auch kombinieren: BODY-I=Z10-20:H4-6:The Simpsons Auch wenn das auf den ersten Blick recht unübersichtlich aussehen mag, ist es dennoch nur die logische Konsequenz: Die Bedingung paßt, wenn in den Zeilen zehn bis zwanzig vier bis sechsmal "The Simpsons" auftaucht. Ebenso lassen sich auch wieder "<" und ">" verwenden. Außerdem ist die Reihenfolge beliebig: BODY-I=H>5:Z<10:The Simpsons Paßt, wenn mehr als fünfmal "The Simpsons" in den ersten neun Zeilen steht. Abschließender Hinweis: Aufgrund der beschriebenen Syntax ist es nicht ohne weiteres möglich, z.B. nach dem *Text* "Z5:Lisa" zu suchen. Ein '\' vor dem Doppelpunkt bietet den Ausweg: BODY-I=Z5\:Lisa 5. DIVERSES In diesem Kapitel finden sich einige allgemeine Hinweise sowie ein paar - 63 - Beispielmuster. Da hier auf dem Wissen der vorherigen Kapitel aufgebaut wird, sollten diese vorher gelesen werden. 5.1 Allgemeine Tips Ich möchte hier noch ein paar allgemeine Tips und Hinweise zu XPFilter in ungeordneter Reihenfolge aufführen, die sich in den vorherigen Kapiteln nicht unbedingt richtig einordnen ließen. o Falls mehrere der Kennungen EXPORT, BATCH, SENDEN, IMPORT, REIMPORT in einem Muster vorhanden sind, werden sie in genau dieser Reihenfolge nacheinander ausgeführt. Dadurch kann eine Kennung auf den vorhergehenden aufbauen, so daß es z.B. möglich ist, eine Nachricht erst zu exportieren, anschließend per Batch zu verändern und zuletzt zu verschicken oder wieder zu reimportieren. Mehrere BATCH-Kennungen werden in der Reihenfolge ausgeführt, in der sie im Muster stehen. o In der Regel ist die Reihenfolge der Muster innerhalb der Musterdateien völlig beliebig. Sie hat praktisch keinerlei Einfluß auf die Bearbeitung und das Ergebnis. Dadurch ist gewährleistet, daß nicht ein Muster als Nebeneffekt ein anderes beeinflußt. Die einzigen Ausnahmen von dieser Regel sind die Verwendung der ABBRUCH- Kennung (->S.22), der STOP-Kennung (->S.38) sowie der Option -a (->S.44). Hier hat logischerweise die Reihenfolge der Muster eine wichtige Bedeutung. Eine nähere Erläuterung dazu findet sich insbesondere bei der Beschreibung der ABBRUCH-Kennung. o Wie wohl leicht zu bemerken ist, ist die Ausführungsgeschwindigkeit von XPFilter je nach Anzahl der Muster und der Puffergröße nicht gerade riesig... Dies liegt hauptsächlich an der Vielzahl an Vergleichen und Plattenzugriffen. Etwas Abhilfe schafft ein Write-Behind Cache, wie z.B. das bei DOS mitgelieferte SmartDrive. Allerdings ist die Benutzung derartiger Programme immer problematisch, da sie alle Daten nur mit Verzögerung auf die Festplatte schreiben und ein unüberlegtes Ausschalten des Rechners oder ein abstürzendes Programm immensen Schaden auf der Festplatte anrichten kann. Ich möchte daher die Benutzung nicht grundsätzlich empfehlen, sie erfolgt auf eigenes Risiko. Bedenkenlos und trotzdem - wenn auch wesentlich weniger - wirksam ist auf jeden Fall ein Read-Cache der sich ebenfalls mit Smartdrive realisieren läßt. Näheres zu all dem steht im DOS-Handbuch. Eine weitere Möglichkeit die Geschwindigkeit zu erhöhen, ist, die Muster - 64 - so zu schreiben, daß möglichst wenig Vergleiche im Nachrichtentext nötig sind, da dieser u.U. sehr lang sein kann. Dazu sollte - wenn möglich - die Suche mit Suchbedingungen für den Header möglichst weit eingeschränkt werden. Wenn aufgrund der Headerbedingungen eine Nachricht auf keinen Fall mehr auf eine Nachricht passen kann, werden alle evtl. vorhandenen BODY bzw. BODY-I Bedingungen nicht mehr getestet. o Es sollte darauf geachtet werden, daß alle von XPFilter *erzeugten* Nachrichten nicht außerhalb des eigenen Points verwendet werden, also z.B. nicht weitergeleitet werden, da weder ihre MID noch ihr ABS inhaltlich der ZConnect-Spezifikation entsprechen. o XPFilter versucht, auch Binärnachrichten erstmal "normal" mit Hilfe der Regulären Ausdrücke zu durchsuchen, da u.U. auch Textnachrichten - aus welchen Gründen auch immer - mit dem Status "binaer" versehen sind. Die Bearbeitung von Binärem wird aber abgebrochen, sobald eine "Zeile" länger als 100 Zeichen ist oder mehr als 30 nicht-ASCII-Zeichen enthält. In diese Fällen handelt es sich mit großer (allerdings nicht näher ausgerechneter :-) Wahrscheinlichkeit um "echt" binäre Nachrichten, bei denen der weitere Test keinen großen Sinn macht. Alle bis dahin gefundenen Treffer durch Suchbedingungen bleiben aber gültig. Nichsdestotrotz werden bei als "binär" deklarierten Nachrichten niemals Veränderungen am Nachrichtentext durchgeführt (z.B. via GRUND (->S.28) oder TEXT (->S.40)) - egal ob obiger Test "bestanden" worden ist oder nicht. Die Gefahr, binäre Daten zu zerstören, ließe sich dabei nicht umgehen. o Von Stefan P. Wolf gibt es eine hervorragende Sammlung von Tools zu CrossPoint und XPFilter, mit denen es z.B. ein leichtes ist, komplette Muster per Tastendruck ( "...at your fingertips" :-) zu erstellen. Näheres dazu findet sich samt Bezugsquellen in der beiliegenden XPFilter-FAQ. Es lohnt sich! | o Die Programmdatei XPFILTER.EXE läßt sich relativ gut mit einem der | diversen EXE-Packer bearbeiten. Falls der Festplattenplatz eng wird, | lassen sich auf diese Weise ca. 90KB einsparen. o Weitere Tips, Hinweise zur Fehlersuche u.a. findet sich ebenfalls in der beiliegenden Datei FAQ.DOC. Die aktuelle Version dieser Liste der "Häufig gestellten Fragen" wird regelmäßig in de.comm.software.crosspoint und /t- netz/support/xpoint/allgemeines gepostet. - 65 - 5.2 Beispiele Hier sollen ein paar vollständige Beispielmuster gezeigt werden, die sich - falls benötigt - mit nur kleinen Änderungen übernehmen lassen. Diese Muster finden sich auch in der Datei BEISPIEL.XPF. 5.2.1 Öffentliche Antworten finden Die wohl häufigste Anwendung eines Filters ist die Suche nach Nachrichten, die auf eigene antworten oder sich auf sie beziehen. Diese sollen dann in der Regel in ein separates Brett kopiert werden. Die einfachste Möglichkeit ist es, in allen Nachrichten nach der Erwähnung des eigenen Namens suchen zu lassen. Da die meisten Schreiber beim Zitieren eine Schablone verwenden, die den Namen des Absenders der Ursprungsnachricht wiederholt, läßt sich ein Großteil der gesuchten Nachrichten auf diese Weise finden: NAME=Meine Post BRETT=/Meine Post EMP=~@ BODY-I=H\.Mustermann|Hans Mustermann END Dieses Muster kopiert alle öffentlichen Nachrichen (->S.13), deren Nachrichtentext "H.Mustermann" oder "Hans Mustermann" in beliebiger Schreibweise enthält, in das Brett "/Meine Post". In Netzen, die eine Bezugsverkettung erlauben, also z.B. im Z-Netz, kann man auch direkt nach Bezuegen auf die eigenen Nachrichten suchen lassen. Dazu muß man wissen, daß der Inhalt einer BEZ-Headerzeile die MID der Bezugsnachricht ist. Die MID einer eigenen Nachricht hat einen variablen, d.h. bei jeder neuen Nachricht unterschiedlichen Teil, sowie einen statischen, der sich nicht verändert. Um den statischen Teil rauszufinden, schaut man am besten mehrere eigene Nachrichten mit Hilfe der Taste 'o' in der Nachrichtenübersicht von CrossPoint an. In der Regel besteht dieser Teil in irgendeiner Form aus der eigenen Adresse. Bei ZConnect-Boxen besteht der statische Teil z.B. aus allem, was in der MID rechts des '@'-Zeichens steht. Angenommen bei Hans Mustermann lautet dieser statische Teil shire.owl.de Dann könnte er zusätzlich zum ersten Muster ein zweites aufnehmen, daß so aussähe: - 66 - NAME=Meine Post BRETT=/Meine Post EMP=~@ BEZ=shire\.owl\.de END Anstatt zwei Mustern könnte man beide allerdings auch mit Hilfe der SUCHEN-Kennung (->S.40) zusammenfassen: NAME=Meine Post BRETT=/Meine Post EMP=~@ SUCHEN= BODY-I="H\.Mustermann|Hans Mustermann" \ || BEZ="shire\.owl\.de" END Da im Fido auch öffentliche Nachrichten einen Empfänger haben, kann man das Verfahren noch derart erweitern, daß auch nach diesen gesucht wird. Dafür kann die X-XP-FTO-Kennung benutzt werden: NAME=Meine Post BRETT=/Meine Post EMP=~@ X-XP-FTO=Hans Mustermann END Auch die X-XP-FTO-Kennung ließe sich noch in die SUCHEN-Bedingung von oben aufnehmen, so daß man alles in einem Muster hätte. 5.2.2 Themen suchen Falls man einfach alle Nachrichten raussuchen möchte, die ein oder mehrere bestimmte Schlüsselwörter erwähnen, genügt ein Muster wie BRETT=/Filter BODY-I=stichwort1|stichwort2|stichwort3|stichwort4 END Alternativ bietet sich anstatt der BRETT-Kennung z.B. auch ATTRIBUT (->S.23) oder MARKIEREN (->S.30) an. Dann werden die gefundenen Nachrichten nicht in ein eigenes Brett kopiert, sondern stattdessen so hervorgehoben, daß sie in der Nachrichtenübersicht ins Auge fallen. 5.2.3 Bretter strukturieren In nahezu allen Netzen gibt es ein Brett, in dem Dinge zum Kauf angeboten bzw. gesucht werden. Die Betreffe der Angebote beginnen i.d.R. mit "V:" oder "B:", Gesuche mit "S:". Um da eine gewisse Struktur rein zu bringen, - 67 - kann man so ein Brett mit Hilfe zweier XPFilter-Muster trennen: NAME=Markt, Suche BRETT=/SUCHE VERSCHIEBEN EMP=/DE/MARKT/MISC|FLEA\.GER BET=^s: END NAME=Markt, Biete BRETT=/BIETE VERSCHIEBEN EMP=/DE/MARKT/MISC|FLEA\.GER BET=^[vb]: END Wenn man ganz konsequent sein möchte, kann man zusätzlich noch alle Nachrichten, die sich nicht an das übliche Schema halten, löschen lassen: NAME=Markt, Rest LOESCHEN EMP=/DE/MARKT/MISC|FLEA.GER BET=~^[svb]: END 5.2.4 Automatische Antworten Angenommen man ist einige Zeit abwesend, läßt den Computer aber automatisch Netzanrufe ausführen. Man könnte dann mit XPFilter jede persönliche Nachricht mit einem kurzen Text beantworten lassen, der dem Absender mitteilt, ab wann man wieder erreichbar ist. Wenn dieser Text in der Datei "C:\TEXTE\REPLY.TXT" stände, könnte das Muster so lauten: NAME=Autom. Antworten SENDEN=C:\TEXTE\REPLY.TXT VAR0=BET TITEL=[AUTOMSG] $0 EINMAL EMP=@ ABS=~maps|areafix|fileserver|mail-server END Dabei schließt die - ggf. noch zu erweiternde - ABS-Bedingung alle Absender aus, die keine Antwort erhalten sollen, was z.B. bei Pseudousern wie MAPS und AREAFIX nötig ist. Der Betreff der verschickten Nachricht ist der der auslösenden. Ihm wird lediglich noch ein "[AUTOMSG]" vorrangestellt. - 68 - 5.2.5 PGP-Schlüssel einlesen Im T-Netz gibt es ein Brett, in dem jeder seinen "Public Key" für das Verschlüsselungsprogramm PGP (Pretty Good Privacy) posten kann. Da dieses sinnvolle Programm besonders gut für EMail geeignet und daher inzwischen sehr weit verbreitet ist, bietet es sich an, dieses Schlüsselbrett automatisch auswerten zu lassen: NAME=PGP Keys EXPORT=key.tmp SWAP BATCH=pgp -ka +batchmode EMP=/T-NETZ/PGP/SCHLUESSEL END (Unter der Annahme, daß sich PGP im DOS-Pfad oder im CrossPoint- Verzeichnis befindet.) Mit SWAP wird XPFilter angewiesen, vor dem Start von PGP möglichst viel Speicher frei zu machen. Das kann u.a. nötig sein, wenn sich bereits eine große Anzahl von öffentlichen Schlüsseln im Keyring befindet. Eine andere Realisierungsmöglichkeit für das automatische Einlesen bestände aus zwei Mustern. Das erste könnte alle PGP Schlüssel in einer Datei aneinanderhängen, und das zweite würde am Ende des Puffers PGP einmal mit dieser Datei aufrufen. 5.2.6 FAQs sammeln FAQs (Frequently Asked Questions, d.h. eine Sammlung häufig gestellter Fragen zu einem bestimmten Thema) bieten häufig eine Fülle von Informationen. Da man sie nach Murphy aber i.d.R. erst braucht, wenn sie bereits gelöscht sind, hab ich mir zwei Muster erstellt, mit deren Hilfe alle FAQs mit einem Komprimierer (in diesem Beispiel PKZIP) automatisch archiviert werden. Das erste Muster exportiert alle passenden Nachrichten in das Verzeichnis FAQS, das ein Unterverzeichnis von CrossPoint sein muß. Dabei wird mit ANHAENGEN exportiert, damit evtl. mehrteilige FAQs komplett erhalten bleiben. Desweiteren ist der Schalter PUFFER vorhanden, damit aus dem Header später der vollständige Betreff sowie das Datum erkannt werden können. Außerdem werden die FAQs der Übersicht halber gleichzeitig noch in ein eigenes Brett verschoben. - 69 - NAME=FAQs sammeln BRETT=/FAQS VERSCHIEBEN EXPORT=FAQS PUFFER ANHAENGEN SUCHEN= BET="faq|howto" || EMP="news/answers" BET=~^& LEN=>2k EMP=~@ END Die Suchbedingungen kann man für diese Anwendung wohl kaum so formulieren, daß sie 100% der FAQs treffen, aber garantiert auf keine anderen Nachrichten passen. Allerdings hab ich mit den in dem Muster stehenden bisher gute Trefferquoten erzielt. Sie sagen aus, daß 1. der Betreff entweder "FAQ" oder "HOWTO" enthalten oder der Empfänger "NEWS/ANSWERS" (ein Brett speziell für FAQs) lauten muß. 2. der Betreff nicht mit "Re:" u.ä. beginnen darf (->S.73). 3. die Länge größer als 2048 Bytes sein muß; alles kleinere ist mit relativ großer Wahrscheinlichkeit keine FAQ... 4. das ganze eine öffentliche Nachricht sein muß. Es wird wie schon gesagt noch ein zweites Muster benötigt, daß das Archivieren übernimmt. Dies geschieht am Programmende mit Hilfe von AMENDE. Es archiviert zuerst alles was im FAQ-Verzeichnis steht. Dabei werden praktischerweise alte FAQs mit demselben Namen automatisch ersetzt. Anschließend wird das FAQ-Verzeichnis komplett gelöscht. NAME=FAQs archivieren AMENDE BATCH=pkzip -ex faqs.zip FAQS\*.* BATCH=echo j|del FAQS END Eine andere Möglichkeit, FAQs zu sammeln, ohne sie extern zu archivieren, besteht darin, sie je nach Thema in unterschiedliche Bretter einzuordnen. Ein interressantes Muster dazu stammt von Markus Kucborski (mk@kutze.prima.ruhr.de): - 70 - NAME=FAQs # hier einfach eine Unterteilung vornehmen, wenn FAQs # aus bestimmten Teilgebieten abgelegt werden sollen. VAR0=EMP:/pgp|/linux|/games|/www|/list # ist die Variable 0 leer, landet alles unter /archiv/faqs BRETT=/archiv/faqs$0 SUCHEN=( ( BET="FAQ|HOW ?TO|frequently asked|\" \ || EMP="/answers" ) \ && QUOTE-ANTEIL<"10" ) \ || BODY-I="^archive.name.*:" LEN=>2k END Enthält ein EMP eine in der VAR0-Definition angegebene Zeichenkette, wandert die FAQ in ein Brett namens "/archiv/faqs" ansonsten nach "/archiv/faqs". 5.2.7 Einschränken von Crosspostings Ein ständig auftretendes Ärgernis stellen die Art von Crosspostings dar, die (z.B.) mehr als fünf Empfänger haben. XPFilter bietet dafür verschiedene Auswege mit Hilfe der Kennung GRUPPEN (->S.19) bzw. GRUPPEN-KOP (->S.19). Eine Möglichkeit wäre es, alle Nachrichten mit mehr als einer gewissen Anzahl Empfängern zu löschen oder in ein "/Junk"-Brett zu verschieben. Eine andere soll hier gezeigt werden: NAME=Massencrosspostings VAR0=EMP BRETT=$0 VERSCHIEBEN LOWPRIO GRUPPEN=>5 END Vorraussetzung für ein vernünftiges Funktionieren dieses Muster ist, daß die Option -d (->S.44) bzw. CHECKDISC in der Konfigurationsdatei benutzt wird. Das Muster verschiebt dann alle Nachrichten mit mehr als 5 Empfängern in das erste in der Brettliste vorhandene Brett und wandelt alle anderen Bretter in Kopieempfänger. Als Ergebnis taucht die Nachricht nur noch in einem Brett auf. Durch LOWPRIO (->S.30) wird erreicht, daß der durch das VERSCHIEBEN entstandene Empfänger (der von XPFilter als "neu" angesehen wird, auch - 71 - wenn er vorher bereits vorhanden gewesen ist), wieder verschwindet, wenn auch ein anderes Muster diese Nachricht mit VERSCHIEBEN oder LOESCHEN bearbeitet. Ein Problem gibt es, wenn noch kein Brett aus der Empfängerliste vorhanden ist (z.B. wenn ein Brett gerade erst bestellt worden ist). In diesem Fall hat die Variable 0 keinen Inhalt und BRETT folglich ebenfalls nicht. In einem solchem Fall setzt XPFilter "/Junk" als Brett ein und verschiebt dorthin (->S.59). 5.2.8 Mailinglisten Mailinglisten sind eine Art Verteiler für Nachrichten. Sie leiten die sie erreichenden Nachrichten an alle eingetragenen Mitglieder der Mailingliste weiter. Es sind quasi öffentliche Bretter, die per Mail verteilt werden. Leider wird das eigene Postfach in der Regel sehr schnell unübersichtlich, wenn man bei mehreren solcher Listen angemeldet ist. Aber alles kein Problem, man hat ja XPFilter. :-) Dazu ist es nur nötig, ein entsprechends Erkennungsmerkmal für all die Nachrichten auszumachen, die aus jeweils einer Mailingliste kommen. Oft ist z.B. ein Weiterleitungsabsender eingetragen, der sich dafür eignet. Beispiel: Wenn alle Mailinglistennachrichten der Liste "MList" mit dem Weiterleitungsabsender owner-mlist@some.where ausgestattet sind, würde folgendes Muster sie in das Brett /Mailinglisten/MList umleiten: NAME=Mailingliste MLIST BRETT=/Mailinglisten/MList VERSCHIEBEN EMP=@ WAB=owner-mlist@some.where END Aber das ist immer noch etwas umständlich, wenn man bei mehreren Listen eingetragen ist, da für jede ein eigenes Muster benötigt wird. Wenn man das Glück hat, daß alle Mailinglisten ein ähnliches Schema für den Weiterleitungsabsender oder den Originalabsender benutzen, dann ermöglichen XPFilters Variablen, alle mit einem Muster zu erschlagen: - 72 - NAME=Mailingslisten BRETT=/Mailinglisten/$0$1$2 VAR0=WAB:1:owner-(.+)@ VAR1=WAB:1:(.+)-owner@ VAR2=OAB:1:(.+)-daemon@ VERSCHIEBEN EMP=@ SUCHEN= WAB="(owner-.+|.+-owner)@" || OAB=".+-daemon@" END Die Variablen 0, 1 oder 2 erhalten damit jeweils den Teil des WAB/OAB, der dem Namen der Mailingliste entspricht, welcher wiederum benutzt wird, um das Zielbrett zu ermitteln. (Auch für dieses Muster Dank an Markus Kucborski!) 6. DAS ZCONNECT-FORMAT Eine Nachricht im ZConnect-Format besteht aus zwei Teilen. Dem "Header" und dem "Body". Der Body enthält den eigentlichen Nachrichtentext in exakt der Weise, wie man ihn beim späteren Nachrichtenlesen zu Gesicht bekommt. Der Header enthält alle Informationen, die zum Transport, Verarbeitung und Einordnung der Nachricht notwendig sind. Getrennt werden beide Teile durch eine Leerzeile. Eine Zeile eines Headers besteht aus einer Kennung, gefolgt von einem Doppelpunkt und dem Inhalt. Eine Absenderzeile sieht z.B. folgendermaßen aus: ABS: robin@shire.owl.de (Robin Sommer) Den gesamten Header einer Nachricht kann man sich in CrossPoint z.B. anzeigen lassen, wenn man in der Nachrichtenübersicht die Taste 'o' drückt. Innerhalb eines Headers gibt es gewisse Zeilen, die Pflicht sind und daher in jeder Nachricht vorhanden sein müssen. Andere dagegen, wie z.B. ein Bezug, sind optional. Die Reihenfolge der Headerzeilen ist beliebig. Eine Beschreibung der wichtigsten Kennungen findet sich im Referenzkapitel (->S.16). - 73 - 7. REGULÄRE AUSRDÜCKE Eines der grundlegenden Dinge in XPFilter sind die "Vollständigen Regulären Ausdrücke", aus der jede Suchbedingung besteht. Mit ihnen lassen sich zu suchende Texte sehr flexibel angeben. Die Syntax in XPFilter entspricht bis auf wenige Ausnahmen der, wie sie von dem UNIX-Tool *egrep* benutzt wird. Ein Regulärer Ausdruck (engl. Regular Expression, kurz RE) ist erstmal nichts weiter als eine Folge von Zeichen, die mit einem Text verglichen wird. Wenn diese Zeichen in derselben Reihenfolge irgendwo im Text vorhanden sind, dann "paßt" der RE auf diesen Text. Im Unterschied zu "normalen" REs spielt bei XPFilter - mit Ausnahme der BODY-Kennung (->S.18) - die Groß-/Kleinschreibung keine Rolle. Innerhalb eines REs gibt es gewisse Steuerzeichen, die eine besondere Funktion ausüben. Wird diese Funktion nicht gewünscht, muß sie ausgeschaltet werden, indem ein '\'-Zeichen davorgesetzt wird. Ein Steuerzeichen ist z.B. der Punkt. Er besagt, daß an dieser Stelle ein beliebiges Zeichen stehen darf und zwar genau eins, nicht mehr und nicht weniger. Wenn man z.B. den RE "ABCD.FGHI" hat, dann paßt dieser sowohl auf "ABCDEFGHI" als auch auf "ABCD#FGHI". Eine Auflistung aller Steuerzeichen folgt unten. Es gibt zwei XPFilter-eigene Steuerzeichen. Einmal die Tilde ('~'), die nur eine Steuerzeichenfunktion hat, wenn sie das *erste* Zeichen des REs darstellt. An allen anderen Stellen wird sie wie ein normales Zeichen betrachtet. Die Wirkung am Beginn des REs besteht darin, daß der Wahrheitsgehalt des gesamten Ausdrucks umgekehrt wird. Der ganze RE paßt also genau dann, wenn der restliche RE, d.h. ohne die Tilde, nicht zutrifft. Das zweite neue Steuerzeichen ist das '&'-Zeichen. Dies behält jedoch an allen Stellen im RE seine Funktion. Sie besteht darin, daß das '&' auf alle Arten von "Re:", "Re^42", u.ä. paßt. Ein Ausdruck wie "&*" paßt damit u.a. auf "Re: Re^2: Re:". Mit einer Suchbedingung wie BET=^& läßt sich z.B. feststellen, ob ein Betreff mit etwas wie "Re:" beginnt (s.u.) oder mit BET=~^& - 74 - ob er nicht damit beginnt. Ein anderes Problem ist festzustellen, ob eine Headerzeile überhaupt vorhanden ist. Falls eine Headerzeile auf jeden Fall einen Inhalt haben muß, läßt sich dies erreichen, indem der ganze RE aus nur einem Punkt besteht. Z.B. testet die Suchbedingung BEZ=. ob eine Nachricht einen Bezug hat. Das umgekehrte Bedingung ist ebenfalls möglich: BEZ=~. prüft, ob kein Bezug vorhanden ist. Allerdings gibt es auch Headerzeilen, die nicht zwingend einen Inhalt haben, wie z.B. "EB" zum Anfordern einer Empfangsbestätigung. In diesem Fall sollte die Bedingung folgendermaßen lauten: EB=.* Damit wird geteset, ob der Inhalt aus Null oder mehr Zeichen besteht... Auch hier funktioniert natürlich die Umkehrung: EB=~.* Es folgt eine Auflistung aller Steuerzeichen: . Platzhalter für genau ein beliebiges Zeichen [] Platzhalter für genau eines der innerhalb der Klammer aufgeführten Zeichen. Ein RE wie "0[ABC]0" paßt sowohl auf "0A0" als auch auf "0B0" als auch auf "0C0". Wenn die Zeichen innerhalb der Klammer in der ASCII-Tabelle direkt aufeinander folgen, kann man auch nur die untere und obere Grenze getrennt durch ein '-'-Zeichen angeben. Damit würde der RE dann lauten "0[A-C]0". Möchte man z.B. einen Platzhalter für eine beliebige Ziffer, hieße der "[0-9]". Die normalen Steuerzeichen haben innerhalb dieser Klammer keine Wirkung, auch das '\'-Zeichen hat keine Sonderfunktion. Die beiden Zeichen '-' und ']' haben als erstes Zeichen nach der öffnenden Klammer keine besondere Funktion, so daß man auch nach ihnen suchen lassen kann. [^] ähnlich wie das vorhergehende mit dem Unterschied, daß dies ein Platzhalter für alle Zeichen ist, die *nicht* innerhalb - 75 - der Klammer auftauchen. * darf nur direkt nach einem anderen Zeichen, einem Platzhalter oder einem Klammerausdruck (s.u.) stehen und bezeichnet eine beliebig häufige Wiederholung davon (auch eine nullmalige Wiederholung!). So würde z.B. der RE "1X*2" sowohl auf "12" als auch auf "1XXXXXX2" passen. + wie '*' mit dem Unterschied, daß eine nullmalige Wiederholung nicht erlaubt ist. ? ähnlich wie '*', allerdings ist keine mehrmalige Wiederholung erlaubt, d.h. das vorhergehende Zeichen muß entweder gar nicht oder genau einmal vorhanden sein. ^ darf nur vor einem Teilausdruck stehen und bewirkt, daß dieser am Beginn des zu vergleichenden Textes stehen muß. Der RE "^XPFILTER" würde auf einen Vergleichstext wie "XPFILTER Version 1.4 " passen, aber nicht auf "Neu: XPFILTER". $ darf nur hinter einem Teilausdruck stehen und bewirkt, daß dieser am Ende des zu vergleichenden Textes stehen muß. () gruppiert Teilausdrücke, die zuerst bewertet werden. Auf diese können dann wieder weitere Steuerzeichen angewandt werden. Beispiel: Der RE "(OH?)+" paßt sowohl auf "OH" als auch auf "OHO" als auch auf "OHOOOOOOOOOHOHO". Klammern können geschachtelt werden. | ODER-Operator, der zum Angeben von Alternativen dient. Der RE paßt dann, wenn entweder der Teil links von '|' oder der rechts davon paßt. Es können auch mehrere aneinander gehängt werden. Ein RE "MEIER|SCHULZE|MÜLLER" würde passen, wenn im Vergleichstext einer der drei Namen auftaucht. \< Diese Kombination steht für den Anfang eines Wortes. Damit läßt sich angeben, daß der folgende Teilausdruck ein Wortbeginn sein soll. \> Steht für ein Wortende. Wenn man dies und das vorherige z.B. zu '\' kombiniert, paßt der RE nur auf das komplettes Wort 'und', nicht aber auf andere Wörter, die auch diese Zeichenfolge enthalten wie z.B. "Gesundheit". Wichtig ist, daß nur solche Zeichenfolgen als Wörter betrachtet werden, die ausschließlich die Buchstaben 'A' bis 'Z', die Ziffern '0'-'9' sowie die deutschen Umlaute enthalten. - 76 - \x wobei x für eine Ziffer von eins bis fünf steht. Damit ist es möglich, den Text anzusprechen, der auf eine vorhergehende Klammer im selben Ausdruck gepaßt hat, wobei die Ziffer die Nummer der zugehörigen Klammer angibt. Beispiel: Der Ausdruck "(.+) +\1" würde auf "abc abc" passen, aber nicht auf "abc def". ~ Nur Steuerzeichen, wenn es das allererste Zeichen des RE ist. Kehrt den Wahrheitswert des REs um (s.o.) & Platzhalter für "Re:" u.ä. (s.o.) \ Deaktiviert, wie bereits weiter oben beschrieben, eine evtl. Steuerzeichenfunktion des folgenden Zeichens Aus diesen Steuerzeichen lassen sich nahezu beliebig komplexe REs zusammenbauen. Ein Beispiel: Der Reguläre Ausdruck xp[- ]?f(ilter|[0-9]| |\.) paßt auf nahezu alles, was irgendwie etwas mit XPFilter zu tun hat, z.B. auf xpfilter xp-filter xp filter xpf xpf140.arj xpf. 8. ERRORLEVEL XPFilter gibt bei einem Fehler einen Errorlevel ungleich Null zurück. Mehr ist z.Z. aus internen Gründen nicht drin... :-)