From: "Joachim Kieferle" Sent: Thursday, March 18, 2004 4:50 PM

Hallo Liste,

Hi Joachim

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

Viele Grüsse

Joachim

Gruß Torsten

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. Gruß, Anke -- Think before you ...

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, 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.

Hallo, Peter Schopen schrieb:

Am Donnerstag, 18. März 2004 19:01 schrieb Joachim Kieferle:

...

Anke Boernig wrote:

...

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?

...

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 -- Think before you ...

Hallo Anke, Am Thu, 18 Mar 2004, Anke Boernig schrieb:

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.

Gefaehrliche Formulierung, denn sie suggeriert "2>&1 >/dev/null" und das macht ja etwas anderes als ">/dev/null 2>&1". Besser: "Mit '>/dev/null' wird die Standardausgabe nach '/dev/null' umgeleitet, und _dann_ durch '2>&1' auch die Fehlerausgabe nach '/dev/null'." bzw.: "Mit '2>&1' wird die Fehlerausgabe auf /dev/stdout umgeleitet und _dann_ durch '>/dev/null' die Standardausgabe (!= /dev/stdout) nach '/dev/null' umgeleitet." $ { echo 'Fehler' >&2; echo "Ok"; } Fehler Ok $ { echo 'Fehler' >&2; echo "Ok"; } 2>&1 Fehler Ok $ { echo 'Fehler' >&2; echo "Ok"; } >/dev/null Fehler $ { echo 'Fehler' >&2; echo "Ok"; } 2>/dev/null Ok $ { echo 'Fehler' >&2; echo "Ok"; } 2>&1 >/dev/null Fehler $ { echo 'Fehler' >&2; echo "Ok"; } >/dev/null 2>&1 $ { echo 'Fehler' >&2; echo "Ok"; } &>/dev/null $ -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.

Normen Dommaschk wrote:

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.

..................................

Full ACK. Auch ich hab' jetzt verstanden, warum es so funktioniert wie's funktioniert. Anke, Peter und besonders David vielen Dank für die ausführlichen Erläuterungen. Viele Grüsse Joachim