Regulärem Ausdruck Befehl anfügen

[psycho82]

Hallo,

ich habe folgendes Problem. Ich möchte an einen Befehl der einen regulären Ausdruck erwartet hinter diesen Ausdruck einen weiteren Befehl anfügen. Bzw. den gesamten Befehl in eine Datei ausgeben.

exipick --spool /tmp/ -i -f <regexp> > datei

Das "> datei" ist mein Problem. Wie kann ich den regulären Ausdruck klammern? Oder gibt es hier eine bessere Lösung?

Gruß

[TheFinn]

Schon mal versucht, den reg. Ausdruck einfach in einfache Anführungszeichen (') einzuschließen?

Oder die Langform zu nehmen, die in der man page angegeben ist?

-f <regexp>

Same as ‘$sender_address = <regexp>’ (exiqgrep)

[psycho82]

Schon mal versucht, den reg. Ausdruck einfach in einfache Anführungszeichen (') einzuschließen?

Oder die Langform zu nehmen, die in der man page angegeben ist?

Also das mit den Hochkommas hab ich schon versucht. Das hilft mir nicht weiter. Und du Langform hilft mir ja auch nicht weiter, da dort ebenfalls nach dem <regexp> die Ausgabe in die Datei folgt.

Verflixtes Problem

[TheFinn]

Hmm, ich glaube, ich hab Dein Problem zuerst mißverstanden: wenn du <regexp> schreibst, meinst Du nicht irgendeinen regulären Ausdruck, sondern einen, der tatsächlich mit den Zeichen '<' und '>' beginnt bzw. endet, korrekt?

Das heißt, Du musst die redirection operators vor der Shell verstecken, aber mit einem einfachen '\' davor kriegst Du irgendwie keinen Treffer mehr auf Deinen regulären Ausdruck?

Habe hier kein exipick, spiele aber ein wenig mit grep an dieser Frage herum und merke mal wieder, daß das Thema Shell + reguläre Ausdrücke + Zeichenmaskierung doch immer wieder, äh, interessant ist...

Edit:

Nee, Quark, geht doch einfach (zumindest mit grep):

grep -E \<f.+o\> > test.out

Bearbeitet 23. Juli 2009 von TheFinn

[psycho82]

Hmm, ich glaube, ich hab Dein Problem zuerst mißverstanden: wenn du <regexp> schreibst, meinst Du nicht irgendeinen regulären Ausdruck, sondern einen, der tatsächlich mit den Zeichen '<' und '>' beginnt bzw. endet, korrekt?

Das heißt, Du musst die redirection operators vor der Shell verstecken, aber mit einem einfachen '\' davor kriegst Du irgendwie keinen Treffer mehr auf Deinen regulären Ausdruck?

Habe hier kein exipick, spiele aber ein wenig mit grep an dieser Frage herum und merke mal wieder, daß das Thema Shell + reguläre Ausdrücke + Zeichenmaskierung doch immer wieder, äh, interessant ist...

Edit:

Nee, Quark, geht doch einfach (zumindest mit grep):

Ne, ich meinte eine regexp ohne "<" und ">". Kannst du vielleicht mal den gesamten grep Befehl nennen? Ich habs mal so probiert:

exipick --spool /tmp/ -i -f | grep -E .*mstbw\.de > file

Und das funktioniert nicht. Hmmm...

[TheFinn]

Ne, ich meinte eine regexp ohne "<" und ">". Kannst du vielleicht mal den gesamten grep Befehl nennen?

Das habe ich im vorigen Posting bereits getan

Ich habs mal so probiert:

exipick --spool /tmp/ -i -f | grep -E .*mstbw\.de > file

Und das funktioniert nicht. Hmmm...

Das kann auch nicht funktionieren mit der Pipe direkt hinter -f...

Wenn das dort genannte Dein Muster ist, Du also nach Absenderadressen in der Domain mstbw.de suchst, sollte theoretisch das folgende funktionieren (wie gesagt, ohne hier ein exipick vor mir zu haben):

exipick --spool /tmp/ -i -f '.*mstbw\.de' > file

[psycho82]

Das habe ich im vorigen Posting bereits getan

Das kann auch nicht funktionieren mit der Pipe direkt hinter -f...

Wenn das dort genannte Dein Muster ist, Du also nach Absenderadressen in der Domain mstbw.de suchst, sollte theoretisch das folgende funktionieren (wie gesagt, ohne hier ein exipick vor mir zu haben):

Genau das ist die Idee, ich such nach den Absenderadressen und möchte deren Mailids in ein File kopieren. Deinen Befehl hier hab ich schon ausprobiert, das geht nicht, das verwundert mich ja so:

exipick --spool /tmp/ -i -f '.*mstbw\.de' > file

[carstenj]

Hi,

ich kenne exipick nicht. Aber was ist hiermit:

exipick --spool /tmp/ -i -f mstbw.de | grep irgendwas  > file 

EDIT: nicht gelesen, dass das schon gepostet wurde. Wieso geht das nicht? Das habe ich noch nicht ganz verstanden.

Du kannst doch ALLE Adresse ausgeben lassen, und anschließend mit Grep die gesuchten filtern.

Bearbeitet 23. Juli 2009 von carstenj

[psycho82]

Hi,

ich kenne exipick nicht. Aber was ist hiermit:

exipick --spool /tmp/ -i -f mstbw.de | grep irgendwas  > file 

Danke für den Tipp, aber dann erhalte ich folgende Fehlermeldung:

cat: *mstbw.de: No such file or directory

edit: @Carsten ... hast du deinen Code nochmal geändert? Sieht so aus, eben stand da noch was anderes

[carstenj]

Hi,

jo, sorry. Hab erst etwas anderes gedacht, und wusste nicht, dass du so schnell antworten würdest.

Wie auch immer, also erstmal alle Adressen ausgeben lassen, und dann mit grep filtern. Das sollte doch, wie von Finn vorgeschlagen, gehen, oder nicht? Wobei, wenn ich mir die Doku angucke, steht da folgendes:

-f <regexp>

Same as ‘$sender_address = <regexp>’ (exiqgrep)

man exipick (8) - selectively display messages from an Exim queue - Linux Manual - Digipedia

Regex sollten also klappen, dann muss der Fehler woanders liegen.

[psycho82]

Also ich versuche das Problem nochmals allgemein zu beschreiben. Ich möchte exipick mir alle MailsIDs in eine Datei schreiben, welche als Absendereintrag mstbw.de haben. Die Option -f erwartet einen regulären Ausdruck. Um die Bildschirmausgabe von exipick in eine Datei umzuleiten muss ich ja > DATEI verwenden. Allerdings "denkt" die Option -f von exipick, dass > DATEI ebenfalls zum regulären Ausdruck gehört und ignoriert die Ausgabe in eine Datei bzw. such Absender die auf "*.mstbw.de > DATEI" hören. Und solche gibt es ja nicht.

Und meinen regulären Ausdruck kann ich mit den Hochkommas nicht ausklammern.

VERSTANDEN?

[psycho82]

So, hab mal etwas getestet. Die zwei folgenden Befehlen funktionieren ohne die Bildschirmausgabe in einer Datei zu speichern:

exipick --spool /tmp/ -i '$sender_address = .*mstbw\.de'

exipick --spool /tmp/ -i -f .*mstbw\.de

Sobald ich die Bildschirmausgabe in eine Datei ausgeben will passiert nichts. Ich warte ein - zwei minuten aber die Datei wird nicht mit IDs gefüllt. Diese beiden Befehle funktionieren nicht:

exipick --spool /tmp/ -i '$sender_address = .*mstbw\.de' > file

exipick --spool /tmp/ -i -f .*mstbw\.de > file

Jemand ne Idee?

[carstenj]

Hi,

also ich hab mir jetzt mal Exim installiert, und bei mir funktioniert das genau so. Das hilft dir jetzt natürllich erstmal nicht weiter.

Jetzt stellt sich mir die Frage, was generell bei Umleitungen passiert. Hast du Schreibrechte in dem Verzeichnis? Funktioniert sowas z.B.?

ls -lart > test.txt

[psycho82]

Hi,

also ich hab mir jetzt mal Exim installiert, und bei mir funktioniert das genau so. Das hilft dir jetzt natürllich erstmal nicht weiter.

Jetzt stellt sich mir die Frage, was generell bei Umleitungen passiert. Hast du Schreibrechte in dem Verzeichnis? Funktioniert sowas z.B.?

ls -lart > test.txt

Bin root und ja ich habe Schreibrechte in dem Verzeichnis. Wenn ich "ls -lart > test.txt" ausführe, wird die Datei erstellt und in der Datei wird der Ordnerinhalt als text gespeichert. Ich habe mal den Befehl: exipick --spool /tmp/ -i '$sender_address = .*mstbw\.de' > file mal ausführen lassen. Die neue Datei wird erstellt und er sucht auch sehr lange in der Mailqueue nach Mails, nur leider schreibt er keine IDs in meine neue Datei.

[lupo49]

Was passiert, wenn du anstelle einer direkten Umleitung von stdout, erst in eine Pipe schreibst und dann nach einem weiterem Befehl in eine Datei?

Bspw.:

exipick --spool /tmp/ -i -f .*mstbw\.de | grep "" > file

Bearbeitet 23. Juli 2009 von lupo49

[psycho82]

Was passiert, wenn du anstelle einer direkten Umleitung von stdout, erst in eine Pipe schreibst und dann nach einem weiterem Befehl in eine Datei?

Bspw.:

exipick --spool /tmp/ -i -f .*mstbw\.de | grep "" > file

Guten Morgen,

Also wenn ich den Befehl so absetze, erhält die Datei das korrekte Änderungsdatum, aber mehr auch nicht. Es wird kein Inhalt in die Datei geschrieben. Ich verstehe das einfach nicht. Setze ich den Befehl ohne die Ausgabe in eine Datei ab, funktionert der Befehl, allerdings erhalte ich dann "nur" eine Ausgabe auf dem Bildschirm und so ist das ja nicht gewünscht.

Bearbeitet 24. Juli 2009 von psycho82

[psycho82]

Ich habe die Ursache des Fehlers/Problems gefunden!

Unsere Mailqueue scheint so groß zu sein, dass der Puffer der Bash sich die korrekte IDs nicht merken kann und somit der Inhalt des leeren Puffers in die Datei schreibt und sie somit nach Durchlaufen des Befehls leer bleibt. Ich habe spaßeshalber nur einige wenige Mails in eine neue Queue kopiert und dann den Befehl abgesetzt und siehe da, es funktionert. Nur leider löst das mein Problem nicht. Ich brauche die IDs in einer Datei :-) Falls jemand Vorschläge hat einfach posten.

Danke

[TheFinn]

Na ja, wenn der zu durchsuchende Namensraum zu groß ist, musst Du ihn aufteilen. Ich sehe jetzt in der man page zu exipick auf den ersten Blick keine Möglichkeit, dies zu tun. Was Du aber machen kannst, ist etwas in dieser Art:

for i in $(seq 1 1 3) do 

     grep -l '$Dein_Suchmuster' spoolfile$i >> matches.txt

done

Die Schleife musst Du natürlich so an den (mir unbekannten) Namensraum Deines Spoolverzeichnisses anpassen, daß Du nicht gerade für jede einzelne Datei im Spool einen neuen grep-Prozess startest...

[psycho82]

Wäre es nicht besser einfach den Inhalt der Queue in mehrere Ordner um zu verteilen und dann diese neuen kleineren Queues mit exipick zu durchsuchen? Das ganz dann mit einem script.

[TheFinn]

Bis zu einem gewissen Grad Geschmackssache, würde ich meinen. Ich hab's deshalb nicht vorgeschlagen, weil ich null Ahnung von exim habe und nicht weiß, ob und wie der mit einer Queue umgehen kann, die auf mehrere Ordner verteilt ist.

[carstenj]

Hi,

mich würde jetzt mal interessieren, um wie viele Einträge es sich überhaupt handelt?!

[psycho82]

Hi,

mich würde jetzt mal interessieren, um wie viele Einträge es sich überhaupt handelt?!

Jetzt werde ich glatt rot. Das Problem ist, dass es so viele Dateien/Mails sind, dass nicht einmal ein "ll" es in einer vertretbaren Zeit schaft den Inhalt der Queue anzuzeigen. Ich kann nur so viel sagen, dass es 15Megabyte an Emails in der Queue sind. Alles reiner Text versteht sich.

Gruß

Bearbeitet 24. Juli 2009 von psycho82

[carstenj]

Hi,

vertretbaren Zeit schaft

könnte es nicht evtl. sein, dass du gar nicht lange genug wartest, bis die Ausgaben in der Datei erscheinen? Du hast weiter oben geschrieben, dass du 1-2 Minuten wartest. Vielleicht reicht das nicht. Ansonsten hören sich 15MB nicht so viel an, als das ein durchschnittliches Linux- oder Unixsystem das nicht verarbeiten könnte.

Ich habe schon aus GB Textdateien mehreren 100tausende Textzeilen rausgefiltert, und das hat auch ohne Probleme geklappt, wenn es auch etwas gedauert hat.

[psycho82]

Hi,

könnte es nicht evtl. sein, dass du gar nicht lange genug wartest, bis die Ausgaben in der Datei erscheinen? Du hast weiter oben geschrieben, dass du 1-2 Minuten wartest. Vielleicht reicht das nicht. Ansonsten hören sich 15MB nicht so viel an, als das ein durchschnittliches Linux- oder Unixsystem das nicht verarbeiten könnte.

Ich habe schon aus GB Textdateien mehreren 100tausende Textzeilen rausgefiltert, und das hat auch ohne Probleme geklappt, wenn es auch etwas gedauert hat.

Ja anfangs war ich nicht geduldig genug. Aber ich habe den Befehl auch schon "fertig" laufen lassen. Ohne Erfolg. Wie gesagt, ich vermute, das es an einem Puffer liegt. Denn sobald ich eine neue Queue erstelle und dort 5 Mailsaus der alten Queue reinkopiere und auf diese neue Queue den Befehl absetze funktioniert alles wunderbar. nur nicht mit der alten Queue. Das Problem muss an einem Puffer liegen, zumindest sagt mir das meine informatische Intuition.

[carstenj]

Hi,

find ich jetzt schon spannend. Ich hab mir mal ein Szenario nachgebaut und etwas rumprobiert:

[B]root@vadmin:~#[/B] time exipick --spool /var/spool/exim4/ -i -f .*ETC_*  | wc -l

17846


real    0m9.987s

user    0m2.408s

sys     0m6.808s

...

root@vadmin:/var/spool/exim4/input# du -sh ./

141M    ./

Das Spool Verzeichnis ist somit 141 Mb groß, und beinhaltet 17846 Nachrichten. Und das ist ein VM System auf meinem Laptop. Evtl. ist deine Perlversion oder Eximversion etwas buggy? Welche nutzt du denn?

root@vadmin:/var/spool/exim4/input# perl --version


This is perl, v5.10.0 built for i486-linux-gnu-thread-multi


root@vadmin:/var/log/exim4# head -10 mainlog

2009-07-23 08:09:09 exim 4.69 daemon started:...

Ist zwar immer nur eine von vielen tausend Möglichkeiten, aber vielleicht hilfts dir ja.