* Denny Schierz wrote/schrieb:
> > Was ist denn dabei Arbeit, die Option "-s" hinter Fetchmail zu schreiben
> > und zus�tzlich STDERR umzuleiten?
> >
> > 1 * * * * fetchmail -s -n 2>/dev/null
>
> mhm, so richtiges f�llt mir da nicht ein, aber, wozu hast du noch -n
> Option drin? Ist das bei dir so damit deine Headers "sauber" sind?
Nee, das ist so, weil ich das schon immer so mache. Irgendwann hatte ich mal
Probleme, die ich mit "-n" l�sen konnte, und jetzt bleibe ich einfach
sicherheitshalber dabei. ;-)
> Dabei f�llt mir noch ein, in welcher man fidnet man die Parameter wie
> zb. "...2>/dev/null" ich wei� nur, das die 2 glaube ich auch
> Fehlermeldungen nach xy sendet, aber da soll es ja noch etliche andere
> Parameter geben.
Nein, etliche andere sind es nicht. 2>/dev/null ist fast schon am oberen
Ende des Spektrums. :-)
man bash, den Abschnitt "REDIRECTION" suchen.
/bin/foo >/tmp/foo.out 2>/tmp/foo.err
Schreibt den Ausgabekanal von /bin/foo nach /tmp/foo.out und die
Fehlerausgabe nach /tmp/foo.err
/bin/foo >/tmp/foo.out 2>&1
Schreibt den Ausgabekanal von /bin/foo nach /tmp/foo.out und schreibt die
Fehlerausgabe dahin, wo es den Ausgabekanal hinschreibt.
Kompliziert wirds nur hier:
/bin/foo 2>&1 >/tmp/foo.out
Schreibt die Fehlerausgabe dahin, wo es den Ausgabekanal hinschreibt, also
zun�chst mal auf die Standardausgabe. Danach wird der Ausgabekanal nach
/tmp/foo.out umgeleitet. Die Fehlerausgabe bleibt aber, wo man sie vorher
hingeschickt hat, n�mlich auf der Standardausgabe. Brrrrrr, sch�ttel! ;-)
Woher die "1" und "2" kommen, solltest Du als jemand, der in der
Berufsschule C lernt, ja besser wissen als ich. :-)
-martin
--
It's not a bug, it's tradition!
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
