Peter Schopen wrote:

Am Donnerstag, 18. März 2004 17:01 schrieb Torsten E.:

wir haben ein Cron-Skript laufen, das von einem Webserver Daten abholt

...

...

und die dann entzippt. Dabei wird die "Konsolenausgabe" stets als Mail an root geschickt. Das soll es aber nicht, solange das Skript sauber läuft. Habe es schon mit "2>&1" und ohne versucht, aber ohne Erfolg. Hat jemand einen kleinen Hinweis, wie ich weiterkomme und die lästigen Mails vermeide?

ein einfaches 2>&1 ist es nicht, sondern ein >/dev/null 2>&1 Beispiel: 10 2 * * * /home/torsten/bin/fetchmail_ml.sh >/dev/null 2>&1

Hi,

Du kannst in der crontab auch als erste Zeile einfügen:

MAIL=""

dann gehen alle mails, die sonst an root gehen ins nirwana.

Gruß Peter

Hallo Torsten, hallo Peter, vielen Dank für die Lösungen. ">/dev/lull 2>&1" ist die "richtige" Lösung für mich, da ich ja noch weiter informiert werden möchte, wenn z.B. ein Cron-Job nicht sauber läuft. Viele Grüsse Joachim

Anke Boernig wrote:

Hallo,

Joachim Kieferle schrieb:

...

Hallo Liste,

wir haben ein Cron-Skript laufen, das von einem Webserver Daten abholt und die dann entzippt. Dabei wird die "Konsolenausgabe" stets als Mail an root geschickt. Das soll es aber nicht, solange das Skript sauber läuft. Habe es schon mit "2>&1" und ohne versucht, aber ohne Erfolg. Hat jemand einen kleinen Hinweis, wie ich weiterkomme und die lästigen Mails vermeide?

Eine Mail kommt immer, sobald ein durch cron ausgeführter Befehl eine Ausgabe veranlasst. Deine Umleitung (2>&1) verstehe ich nicht so ganz - damit leitest Du nur die Fehlerausgabe in die Standardausgabe mit um. Was Du probieren kannst, ist ein Aufruf des Skripts mit einem "&>/dev/null" am Ende:

17 */1 * * * /cron-scripts/arch_ides_runterladen.sh &>/dev/null

Damit werden dann alle Ausgaben des Skripts ins Nirwana geschickt, also gibt's auch keine Mails. Dann solltest Du aber im Skript abfragen, ob die Sicherung erfolgreich war, und bei Misserfolg eine Mail an root schicken lassen.

Hallo Anke, vielen Dank. Es funktioniert sowohl die "> /dev/null 2>&1" als auch "&>/dev/null". Beidesmal werde ich von Mails "verschont". Welche Lösung jetzt besser ist, kann ich leider auch nicht sagen, aber vielleicht kann das jemand erläutern? Viele Grüsse Joachim

Hallo, Am Thu, 18 Mar 2004, Peter Schopen schrieb:

auf die schnelle würde ich im ersten Fall sagen:

...

/dev/null 2>&1 . die 2 bedeutet Fehlerkanal (STDERR), also alle Fehlerausgaben und die 1 Standardausgabe/Monitor (STDOUT) wird ins nirwana (/dev/null) geschickt. im zweiten Fall bin ich mir aber nicht sicher. eigentlich bedutet das "&": starte den Job im Hintergrund ">/dev/null" alle Ausgaben ins nirwana. Ob dann aber auch Fehler nach /dev/null gehen ??? Morgen im Büro werde ich die beiden Lösungen mal ausprobieren.

RTFM! Nebenan zitiere ich die Stelle und schreibe auch, wie ich die Stelle zu finden ist. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.

Am Donnerstag, 18. März 2004 20:18 schrieb Anke Boernig:

Peter Schopen schrieb:

...

...

vielen Dank. Es funktioniert sowohl die "> /dev/null 2>&1" als auch "&>/dev/null". Beidesmal werde ich von Mails "verschont". Welche Lösung jetzt besser ist, kann ich leider auch nicht sagen, aber vielleicht kann das jemand erläutern?

...

auf die schnelle würde ich im ersten Fall sagen:

...

/dev/null 2>&1 . die 2 bedeutet Fehlerkanal (STDERR), also alle

Fehlerausgaben und die 1 Standardausgabe/Monitor (STDOUT) wird ins nirwana (/dev/null) geschickt. im zweiten Fall bin ich mir aber nicht sicher. eigentlich bedutet das "&": starte den Job im Hintergrund ">/dev/null" alle Ausgaben ins nirwana. Ob dann aber auch Fehler nach /dev/null gehen

Deine Deutung stimmt nicht so ganz.

...

Beide Versionen machen nämlich genau dasselbe :-)

Mit dem "2>&1" lenkt man die Standard-Fehlerausgabe in die Standardausgabe, und mit dem "> /dev/null" die Standard-Ausgabe nach /dev/null. Und da die Fehlerausgabe in die Standardausgabe umgeleitet wurde, geht also alles nach /dev/null. Und das "&>" bedeutet genau dasselbe, dass nämlich sowohl die Standardausgabe als auch Fehlerausgabe umgeleitet werden sollen.

Und da ich etwas tippfaul bin, nehme ich immer die Variante :-)

...

Gruß, Anke

Hallo, stimmt. Als Hintergrundjob wird das ganze gestartet, wenn hinter dem "&" eine Leerstelle (space) steht. Grüße Peter

Hallo zusammen, auch wenn ich nichts produktives zu diesem Thread beitragen kann, moechte ich mich doch fuer die vielen Antworten auf Joachim?s Mail bedanken. Hat auch mir sehr weitergeholfen. .................................. Gruss und bis denne..... Normen "I heard if you play the NT-4.0-CD backwards, you get a satanic message" "That's nothing, if you play it forward, it installs NT-4.0"

Hallo, Am Thu, 18 Mar 2004, Joachim Kieferle schrieb:

vielen Dank. Es funktioniert sowohl die "> /dev/null 2>&1" als auch "&>/dev/null". Beidesmal werde ich von Mails "verschont". Welche Lösung jetzt besser ist, kann ich leider auch nicht sagen, aber vielleicht kann das jemand erläutern?

Beides sind aequivalente Umleitungen. Erste Fundstelle von '&>' in man bash: ==== man -P'less +/\&\>' bash ==== There are two formats for redirecting standard output and standard error: &>word and >&word Of the two forms, the first is preferred. This is seman­ tically equivalent to >word 2>&1 ==== Fuer "word" haben wir im Beispiel "/dev/null". -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.