Hallo Thorsten, Am Sat, 22 Nov 2003, Thorsten Haude schrieb:
* David Haller
[2003-11-20 02:18]: Am Tue, 18 Nov 2003, Thorsten Haude schrieb:
* David Haller
[2003-11-18 01:30]: Welche unserer procmail vs. Mail::Audit (oder was verwendest du noch gleich?) Diskussionen meinst du? Wenn du die IIRC letzte meinst, dann hatte ich da schlicht nix mehr zu zu sagen.
Und scheinbar auch nichts mehr zu lesen. Versuch's doch nochmal, vielleicht findest Du ja doch etwas Interessantes.
Ok, sorry. Du verwendest maildrop, nicht Mail::Audit. Da hab ich was durcheinandergebracht.
Uh. Nein, wieder falsch, ich benutze beides.
Mann, du machst's einem aber auch schwer! Poeser Pursche tu! [..]
Benutzbar ist procmail. Ob einfacher oder schwieriger fuer einen "Newbie" (der auch kein perl, keine shell usw. kennt!) als maildrop, das kann ich nicht beurteilen.
Noch kennt der Newbie keine Shell, die wird er aber über kurz oder lang brauchen, also hilft die Ähnlichkeit.
Ok. Die "Aehnlichkeit" der Syntax zu shell/perl etc. ist ein Vorteil.
Ist maildrop eigentlich bei der SuSE dabei? Lt. nem 'zgrep maildrop SuSE-8.2-ARCHIVES.gz' ist das nicht der Fall. Da man "$NEWBIE" auch nicht gleich ne Kompilation an den Hals haengen will, haben wir ein Dilemma. Hast du mal angeregt, dass maildrop in der SuSE landet?
Auf meinen SuSEs war das immer dabei, solange ich das Programm benutze.
Das ist dann aber noch nicht allzu lange ;) Als ich konkret ein Filter-Programm brauchte, war's jedenfalls defitiv noch nicht auf der SuSE dabei... dh@slarty[1]: ~ (0)$ zgrep maildrop /.../SuSE-6.2-ARCHIVES.gz dh@slarty[1]: ~ (1)$ Hm. Wann kam die 7.1 raus? Da war maildrop dann offenbar dabei... Apropos, ich muss mal mein Archiv von ARCHIVE.gz/INDEX.gz/ls-lR.gz-Dateien vervollstaendigen ;)
Wenn die das jetzt nicht mehr liefern, frage ich mich natürlich bösartig, ob die damit rechnen, am Support für Procmail mehr Geld zu verdienen als am Support für Maildrop.
Jo, is seltsam, dass es scheinbar nicht mehr dabei ist...
Ich hab mir jetzt maildrop mal gesaugt und kompiliert, aber noch nicht installiert. Ich will mir das erstmal genauer anschauen und testen.
Gut!
Gell?
[Apropos an die Mitleser: maildrop ist teils in C, teils in C++ (leicht chaotisch vermengt) geschrieben, sollte also fast so flott beim Starten sein wie procmail.
Na, dann will ich mal hoffen, daß es auch darüber eine Statistik geben wird.
Ok, mach ich dann, wenn moeglich. Wg. libstdc++ duerfte es aber nen Tick langsamer bei starten sein... Mehr Sorgen macht mir eh das chaotische Vermengen von C und C++...
Die kam bei mir erst recht spaet an. Die Eleganz daran kann man der nicht absprechen (v.a. wenn der Inhalt von $FROM eine einfache RE auf die Relevanten Header ist).
Ne, das ist der Message Envelope Sender,
Also nicht (auch) der "From: "-Header? Dann ist die Variable aber irrefuehrend benamst.
die Regexe stecken in der Datei, die Du mit lookup einliest.
Ja, das war schon klar. Ich dachte, dass in $FROM sowas wie: '(From |X-Envelope-From: |From: |Sender: )' drinsteckt, auf die dann die aus der Datei eingelesen REs gematcht werden. [..]
Ratti's Loesung ist gut, hat aber den Nachteil formail und fgrep aufzurufen (was auf alten Kisten relevant sein kann).
Denk daran nochmal, wenn Du dann mißt, ob Procmail schneller ist als Maildrop.
Ja, klar.
Im Prinzip fehlt procmail ein Substitutionsmechanismus, der sowas wie
* ^Foo: (`perl -e '@_=<>;chomp(@_);print join("|",@_), "\n";' < FILE`)
machen wuerde, wuerde procmail das `` ausfuehren.
Ok, bei Procmail mit inline Perl gebe ich mir nichtmal Mühe: Was bewirkt diese Zeile?
Garnix, denn das `` geht in procmail nicht :) Ich schrieb ja: procmail "*fehlt*" sowas wie... Der perl-Befehl bastelt einfach aus zeilenweise in einer Datei "FILE" abgelegten REs eine "grosse" RE: ^Foo: (zeile1|zeile2|...|zeileN) Was der perl-Befehl macht kannst du leicht mittels einem: echo -e 'a\nb\nc' | perl -e '@_=<>;chomp(@_);print join("|",@_);' nachvollziehen. Das ', "\n"' am Ende ist flasch, war aber ja eh nur "meta-code" ;) Und jetzt pack das Ergebnis noch in umgebende () und du hast eine egrep-RE ;) Aber wie gesagt: _das_ geht in procmail nicht, dass man teil-REs aus einer Datei so einliest. Wenn es das gaebe, das waere schon praktisch, eben z.B. fuer ein killfile: :0 * ^From: (`perl -e ... < killfile`) /dev/null Wobei man eigentlich das `perl ...` intern erledigen sollte, is ja eigentlich kein Aufwand, ist ja nur ein "tr '\n' '|'" oder so...
[lass uns den Editor-War diesmal auslassen, ok?]
Ooch menno...
XEmacs RULEZ!!!!
Ok, wie wär's mit einem Tausch: Ich fixe meinen Msg-ID und Du rätst in Zukunft den armen Newbies zu Maildrop?
Nein. Dazu kenne ich maildrop (noch!) nicht genug. Das musst du also noch ne Weile allein machen.
Ich kann warten (hehe).
Gut.
Dazu hab ich das figlet.el allerdings noch etwas aufbohren muessen[1], aber ich vermute mal, fuer die gleiche Funktionalitaet musst du bei vim und nedit auch "Hand anlegen" :)
Ne, ein figlet-Modul gibt es nicht wirklich für NEdit. Ist wohl auch nicht so kompliziert, daß man es nicht mal eben selbst machen kann.
Jep. ,----[ ~/.xemacs/lisp/sh-cmd.el ] | (defun figlet-on-region () (interactive) | (shell-command-on-region (region-beginning) (region-end) "figlet" t)) | | (defun figlet-on-region-with-font (font) | (interactive list (read-from-minibuffer "Font: ")) | (setq command (concat "figlet -f " font)) | (shell-command-on-region (region-beginning) (region-end) command t)) `---- Das ist IMO sogar wenn man kein eLisp kenn noch halbwegs nachvollziehbar ;) Den interaktiven Kram und die Variablendefinition musst du eben auf die passenden Makros usw. umbiegen...
Ansonsten bin ich sicher, eine ähnliche Kurzsichtigkeit bzgl. Msg-IDs an den Tag legen zu können
Bitte nicht. Wer hat das RfC 2822 rausgekruschtelt? Ah, danke Mathias Bauer! Bitte lese dir da den genannten Abschnitt 3.6.4 durch. Eine gueltige Msg-ID ist auch in deinem Sinne!
Ja klar, ich sehe nur nicht die hohe Priorität.
Ich schon.
(Mail::Audit-Syntax ist übrigens Perl. Du würdest vermutlich etwa 30 Sekunden brauchen, um zu verstehen, wie man da Filter schreibt, die alles in den Schatten stellen, was Procmail zu bieten hat.)
Ja, dafuer ist aber die Performance fuer mich nicht brauchbar ;)
<shrug/> Geht deutlich schneller, als ich die Mails lesen kann, also stört's mich nicht. Mein Rechner steht eh den längsten Teil des Tages nur 'rum.
Bei mir kommen Mails halt "im Schwung" rein, da meine Kiste nur laeuft, wenn ich auch davor sitze... Und online bin ich dann auch nicht oft... Kurz, da sind dann halt gern mal 300-500 Mails in der queue, und da ist dann die Verarbeitungszeit pro Mail dann doch interessant...
PS: ich finde es gut, dass du (wie ich bei anderen Sachen) immer wieder Alternativen nennst, weiter so! Nur dein "Tonfall" neigt manchmal zum poltern ;)
Jepp.
*g* Wegen mir kannst du ja ruhig "rumpoltern", ich kenn das ja von dir und hab auch keine Probleme damit :) Andere kennen / moegen das aber weniger... Generell waere es u.U. passender, wenn du hier versuchst, das poltern etwas zu reduzieren ;) -dnh, der ja auch ab und an mal etwas deutlicher wird :) -- } Some time ago, ISawAGN for the Mind::Reader package. Still can't find it } on CPAN. -- } Satya and Rik The DrillImpenetrableMatter() and ExtractNonexistentInfo() functions are still giving all kinds of trouble. Let's not even speak about Coherentify().