On Mon, Jul 12, 2004 at 06:47:41AM +0200, Bertram Scharpf wrote:
test `ls -A /voller/pfad | head -n 1`
Meines wissens bricht `ls' ab, wenn die Pipe geschlossen
wird.
AFAIK schließt head die pipe aber nicht.
Gruß
Christian
--
Christian Knoke* * *
Hallo Christian,
Am Montag, 12. Jul 2004, 09:11:27 +0200 schrieb Christian Knoke:
On Mon, Jul 12, 2004 at 06:47:41AM +0200, Bertram Scharpf wrote:
test `ls -A /voller/pfad | head -n 1`
Meines wissens bricht `ls' ab, wenn die Pipe geschlossen
wird.
AFAIK schließt head die pipe
Markus Schulz wrote:
Klingt gut.
Noch eine Frage dazu, ist es nicht besser False Positives mit der
--forget Option von sa-learn zu lernen, anstatt diese als Ham zu
lernen? (zumindest bei eingeschaltetem Auto-Learn)
Ich würde sagen besser wäre --ham. Bei --forget lässt Du die bayesDB
glauben die
Hallo,
Am Montag, 12. Jul 2004, 09:24:27 +0200 schrieb Bertram Scharpf:
Am Montag, 12. Jul 2004, 09:11:27 +0200 schrieb Christian Knoke:
On Mon, Jul 12, 2004 at 06:47:41AM +0200, Bertram Scharpf wrote:
test `ls -A /voller/pfad | head -n 1`
Meines wissens bricht `ls' ab, wenn
Am Montag, 12. Juli 2004 06:47 schrieb Bertram Scharpf:
Am Sonntag, 11. Jul 2004, 20:05:08 +0200 schrieb Jan Trippler:
if test `ls -a /voller/pfad | wc -l` -gt 2; then
..
fi
Mir fällt da noch etwas ein, wie man verhindert, daß das
ganze Verzeichnis gelesen wird:
test `ls -a
Bertram Scharpf wrote:
test `ls -A /voller/pfad | head -n 1`
Meines wissens bricht `ls' ab, wenn die Pipe geschlossen
wird.
AFAIK schließt head die pipe aber nicht.
Habe mir gerade den Quellcode angesehen. Wenn genügend
Zeilen gelesen wurden, wird kein `read' mehr aufgerufen,
sondern gleich
On Mon, Jul 12, 2004 at 10:50:04PM +0200, Danijel Tasov wrote:
Bertram Scharpf wrote:
test `ls -A /voller/pfad | head -n 1`
Mal ganz davon abgesehen, dass ls hoechstwarscheinlich schon das ganze
Verzeichnis gelesen hat, bevor es auch nur 1 Byte ausgibt, es sortiert
naemlich die Ausgabe.
Christian Knoke wrote:
Mal ganz davon abgesehen, dass ls hoechstwarscheinlich schon das ganze
Verzeichnis gelesen hat, bevor es auch nur 1 Byte ausgibt, es sortiert
naemlich die Ausgabe.
ls -U
Selbst das verhindert nicht, dass ls nicht erst das ganze Verzeichnis liest.
--
Haeufig gestellte
Markus Schulz wrote:
Allerdings benutze ich Shared IMAP Folder (SPAM/HAM/Missed Spam) die
mittels Cyradm so eingestellt wurden, das nur EMails dort reingeschoben
werden dürfen.(lesen nicht erlaubt)
Dann weisst Du aber nicht (ohne weiteres) wem die Mails gehören,
z.B. um sie zurück zu liefern
Bjoern Schmidt wrote:
Ein riesiges Problem ist noch ungelöst: Beim verschieben können
Mails in Trash und learned überschrieben werden!
Ach ja, und wenn einer nen Ordner nach Spam oder Ham schiebt wirds
vermutlich auch die mboxlist durcheinander bringen. Das Problem
vernachlässige ich aber weil
Bjoern Schmidt wrote:
Markus Schulz wrote:
Allerdings benutze ich Shared IMAP Folder (SPAM/HAM/Missed Spam) die
mittels Cyradm so eingestellt wurden, das nur EMails dort
reingeschoben werden dürfen.(lesen nicht erlaubt)
Dann weisst Du aber nicht (ohne weiteres) wem die Mails gehören,
z.B. um
Markus Schulz schrieb:
Das würde ich in der cyrus.conf eintragen, nicht in der crontab.
Dann bist Du nämlich schon cyrus.
Das wollte ich mir auch noch einmal anschauen. Das Problem ist dabei,
das Spamassasin von Amavis aufgerufen wird und daher die Dateien auch
Amavis gehören.
Das ist
Björn Schmidt wrote:
Das ist unlogisch. Amavisd-new nimmt Mails per tcp von postfix/exim
entgegen, prüft sie und gibt sie wieder an postfix/exim zurück, ohne
deren Besitz zu übernehmen. postfix/exim gibt sie dann an cyrus/sieve
weiter, welcher sie in die Maildirs legt.
War wohl ein Mißverständnis.
Am Samstag, 10. Juli 2004 22:55 schrieb Bertram Scharpf:
Am Samstag, 10. Jul 2004, 19:50:00 +0200 schrieb Jan Trippler:
[...]
Ein leeres Verzeichnis hat immer exakt 2 Links - einmal auf ..
und einmal auf .
Leider nicht. Die beiden Hardlinks sind
/voller/pfad
/voller/pfad/.
Nach
Hallo,
Am Sonntag, 11. Jul 2004, 20:05:08 +0200 schrieb Jan Trippler:
if test `ls -a /voller/pfad | wc -l` -gt 2; then
..
fi
Mir fällt da noch etwas ein, wie man verhindert, daß das
ganze Verzeichnis gelesen wird:
test `ls -a /voller/pfad | head -n 3 | wc -l` -gt 2
oder noch
Ich habe es jetzt so gelöst:
if [ -z $(find $MAILSPOOL/$1/Spam/ -type d -empty) ]; then
lerne...
fi
Danke an alle für die Tipps!
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN
Hallo,
Am Donnerstag, 08. Jul 2004, 18:20:40 +0200 schrieb Bjoern Schmidt:
Bjoern Schmidt wrote:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht... ;)
Habe nochmal ein wenig probiert. 'test -s ...' scheint zu
Bertram Scharpf wrote:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht... ;)
Habe nochmal ein wenig probiert. 'test -s ...' scheint zu funktionieren.
Bei mir nicht. Schade eigentlich.
Kann auch nicht, ist nämlich
Bjoern Schmidt [EMAIL PROTECTED] writes:
if [ -z $(find /voller/pfad -type d -empty) ]; then
mach was...
fi
Das durchsucht den ganzen Baum und gibt auch wahr zurück, wenn das
gewünschte Verzeichnis gar nicht leer ist, sondern irgendein
Unterverzeichnis. Außerdem klappt es nur, wenn
On Sat, 10 Jul 2004, Heike C. Zimmerer wrote:
if [ -z $(find /voller/pfad -type d -empty) ]; then
mach was...
fi
Das durchsucht den ganzen Baum und gibt auch wahr zurück, wenn das
gewünschte Verzeichnis gar nicht leer ist, sondern irgendein
Unterverzeichnis. Außerdem klappt es nur,
Am Samstag, 10. Juli 2004 19:24 schrieb Bjoern Schmidt:
On Sat, 10 Jul 2004, Heike C. Zimmerer wrote:
[...]
if [ -z $(find /voller/pfad -type d -empty -maxdepth 0) ];
then
^^^ ^
Werde ich umgehend aendern. Hoffe dann ist es endlich
Hallo,
Am Samstag, 10. Jul 2004, 19:50:00 +0200 schrieb Jan Trippler:
Am Samstag, 10. Juli 2004 19:24 schrieb Bjoern Schmidt:
On Sat, 10 Jul 2004, Heike C. Zimmerer wrote:
[...]
if [ -z $(find /voller/pfad -type d -empty -maxdepth 0) ];
then
^
Bjoern Schmidt wrote:
Pierre Gillmann wrote:
Aber wie es in einem Skript aussehen könnte, weiß ich jetzt nicht so
genau, da ich auch dein Skript nicht kenne, aber vielleicht helfen dir
meine Beispiele weiter.
Ja tun sie, danke. Mein cron-Skript (lernt Ham-Mails in die globale
bayesdb) sieht so
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht... ;)
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 8. Juli 2004 17:11 schrieb Bjoern Schmidt:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht...
;)
Mit test direkt geht das wohl nicht. Vielleicht kannst
Am Do, den 08.07.2004 schrieb Bjoern Schmidt um 17:11:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht... ;)
Ich würde dazu du Verwenden oder find ;)
Mit find:
find ./ -type d -empty
Mit du hab ich schon öfters
Michael Koch wrote:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht...
;)
Mit test direkt geht das wohl nicht.
Schade. Wäre mir am liebsten... :(
Vielleicht kannst du mit
folgendem was anfangen:
COUNT=`ls $DIR | wc
Pierre Gillmann wrote:
Am Do, den 08.07.2004 schrieb Bjoern Schmidt um 17:11:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht... ;)
Ich würde dazu du Verwenden oder find ;)
Bei Du 'du' ist die Laufzeit wie bei 'ls'
Bjoern Schmidt wrote:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder nicht... ;)
Habe nochmal ein wenig probiert. 'test -s ...' scheint zu funktionieren.
--
Mit freundlichen Gruessen
Bjoern Schmidt
--
Haeufig gestellte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 8. Juli 2004 17:35 schrieb Pierre Gillmann:
Am Do, den 08.07.2004 schrieb Bjoern Schmidt um 17:11:
Wie kann ich testen ob ein Verzeichnis leer ist? (man|info) test
sagen dazu leider nichts aus. Oder ich sehe es mal wieder
Hi,
Mit du hab ich schon öfters was versucht, bisher ohne
zufriedenstellendes Resultat, aber find funktioniert.
Sucht es nur nach leeren Verzeichnissen, oder kann es auch bestätigen?
Falls ja, wie müsste das in einem Script aussehen?
Also Michael hat ja ein Beispiel gegeben und wenn du
Pierre Gillmann wrote:
Aber wie es in einem Skript aussehen könnte, weiß ich jetzt nicht so
genau, da ich auch dein Skript nicht kenne, aber vielleicht helfen dir
meine Beispiele weiter.
Ja tun sie, danke. Mein cron-Skript (lernt Ham-Mails in die globale
bayesdb) sieht so aus:
#!/bin/sh
Am Donnerstag, 8. Juli 2004 18:36 schrieb Pierre Gillmann:
[...]
kritisch werden). Lschen tue ich dann z.B. so: rm -rf $(find ./
-type d -empty) kannst du natrlich x-beliebig abndern und ja
ich wei, es gibt noch -exec, nur mit dem konnt ich mich noch
nicht anfreunden.
Der ist aber um einiges
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Donnerstag, 8. Juli 2004 19:10 schrieb Bjoern Schmidt:
Pierre Gillmann wrote:
Aber wie es in einem Skript aussehen könnte, weiß ich jetzt nicht
so genau, da ich auch dein Skript nicht kenne, aber vielleicht
helfen dir meine Beispiele weiter.
Michael Koch wrote:
Mal so eine Idee:
Da es ja sein kann dass der Cronjob nix zu tun
nicht schlimm, dann tut er eben nichts.
oder der Job mal eine Zeit lang nicht läuft
Das ist unwahrscheinlich, der Rechner ist 24/7 uponline...
obwohl eine Mail angekommen ist, wäre es nicht
besser sowas wie
Am 2004-07-08 18:16:29, schrieb Bjoern Schmidt:
Mit find:
find ./ -type d -empty
Hmm, wenn ich find richtig verstanden habe sucht es (rekursiv) nach
Dateien/Verzeichnissen gemäß der durch Parameter vorgegebenen
matches. Ich habe aber schon ein Verzeichnis von dem ich wissen
möchte ob es leer
36 matches
Mail list logo
