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?
Viele Grüsse
Joachim
+++ Hier der Cron-Eintrag:
17 */1 * * * /cron-scripts/arch_ides_runterladen.sh
+++ und hier das Skript arch_ides_runterladen.sh:
#!/bin/sh
cd /usr/local/sav
/usr/bin/wget -N -r -nH --cut-dirs=2
http://www.sophos.de/downloads/ide/377_ides.zip 2>&1
sleep 10 2>&1
/usr/bin/unzip -o /usr/local/sav/377_ides.zip 2>&1
+++ und so sieht die Mail vom cron-Daemon an root aus, egal ob ein oder
kein neuer File heruntergeladen wird.
Subject: Cron
From: "Joachim Kieferle"
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
Am Donnerstag, 18. März 2004 17:01 schrieb Torsten E.:
From: "Joachim Kieferle"
Sent: Thursday, March 18, 2004 4:50 PM
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
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
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
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?
Hallo Liste, als erstes... ich lese regelm. die Liste mit, Antworte und Frage allerdings selten, weil meiner Meinung nach viel zu oft als Anwort kommt: "man xyz". Heute abend scheint das anders zu sein !!!!!! 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.
Gruß Peter
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.
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 ...
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 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.
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"
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
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.
participants (6)
-
Anke Boernig
-
David Haller
-
Joachim Kieferle
-
Normen Dommaschk
-
Peter Schopen
-
Torsten E.