Hi! Ich hab ein Sicherungsscript, dass ich mit ./script.sh & >> log.txt aufrufe um alle Meldungen der Befehle des Scripts im Logfile zu haben. Nun hab ich einige Rsync Kopieraktionen in dem Script und will von Rsync wissen, welche Dateien nicht kopiert werden konnten (also keine Skips - richtige Fehler), und eine Zusammenfassung im Logfile haben - wie muß ich das rsync mitteilen? lg
Martin Hochreiter wrote at Tuesday, October 04, 2005 8:02 AM
Ich hab ein Sicherungsscript, dass ich mit ./script.sh & >> log.txt ^^^^ aufrufe um alle Meldungen der Befehle des Scripts im Logfile zu haben.
AFAIK Darf hier KEIN Leerzeichen zwischen dem Ampersand (Dateideskriptor) und den "Größer" Zeichen stehen, vielleicht ein Grund, dass Du im Log nicht das siehst, was Du sehen willst. Ich habe mit dieser Schreibweise (Umleitung von stdout _stderr_ _und_ Anhängen an eine Datei auch schon öfter eigenartiges Verhalten beobachtet, versuch es mal mit "./script.sh >> log.txt 2>> log.txt" ... Sollte eigentlich das selbe bewirken, tut es aber wie gesagt zumindest bei der Bash von SuSE nicht immer. Alternativ würde ich mal versuchen, die Umleitung am Anfang des Scriptes mit dem Eintrag: "exec >> /pfad/zum/log.txt 2>> /pfad/zum/log.txt" zu erreichen. Hier funktioniert die Schreibweise mit "&>>" übrigens _definitiv_ nicht, warum auch immer. Aufrufen kannst Du das Skript dann gleich ohne Konsolenbezug mit: "startproc -s /pfad/zum/script.sh". Generelles zur output redirection ist zB hier sehr gut beschrieben: http://www.thomashertweck.de/redir.html http://www.tldp.org/LDP/abs/html/io-redirection.html (letzteres ist überhaupt eines der besten mir Bekannten Manuals zum Bash-Scripting.)
Nun hab ich einige Rsync Kopieraktionen in dem Script und will von Rsync wissen, welche Dateien nicht kopiert werden konnten (also keine Skips - richtige Fehler), und eine Zusammenfassung im Logfile haben - wie muß ich das rsync mitteilen?
IMHO schreibt rsync Fehler immer nach stderr wenn es _nicht_ mit der Option -q (für "quiet") aufgerufen wurde. Um mehr Mitteilungen zu erhalten, gibt es -v ("verbose"), da werden aber auch alle erfolgreich kopierten Dateien angeführt, in einem Logfile also vielleicht eher unerwünscht. Weiters gibt es noch die Option --stats, die eine Zusammenfassung erzeugt, ich weiss aber nicht genau, was deren Inhalt ist, auf alle Fälle sind darin die Gesamtverbindungsgeschwindigkeit etc enthalten. HTH Regards, Markus
On Tue, Oct 04, 2005 at 08:45:54AM +0200, Markus Heidinger wrote:
Martin Hochreiter wrote at Tuesday, October 04, 2005 8:02 AM
Ich hab ein Sicherungsscript, dass ich mit ./script.sh & >> log.txt ^^^^ aufrufe um alle Meldungen der Befehle des Scripts im Logfile zu haben.
AFAIK Darf hier KEIN Leerzeichen zwischen dem Ampersand (Dateideskriptor) und den "Größer" Zeichen stehen, vielleicht ein Grund, dass Du im Log nicht das siehst, was Du sehen willst.
Doch, ist ok. "background" und "anhaengen" sind die beiden Features, die diesem Aufruf mitgegeben werden.
Ich habe mit dieser Schreibweise (Umleitung von stdout _stderr_ _und_ Anhängen an eine Datei auch schon öfter eigenartiges Verhalten beobachtet, versuch es mal mit "./script.sh >> log.txt 2>> log.txt" ... Sollte eigentlich das selbe bewirken, tut es aber wie gesagt zumindest bei der Bash von SuSE nicht immer.
Es ist empfehlenswert noch "2>&1" anzuhaengen, damit auch die Fehlermeldungen in log.txt auftauchen. Peter
Peter Wiersig wrote at Tuesday, October 04, 2005 9:23 AM Hallo, Also entweder bin ich gerade dabei, dazu zu lernen (was ja positiv ist) oder ich bin einfach verwirrt ...
Ich hab ein Sicherungsscript, dass ich mit ./script.sh & log.txt ^^^^ aufrufe um alle Meldungen der Befehle des Scripts im Logfile zu haben.
AFAIK Darf hier KEIN Leerzeichen zwischen dem Ampersand (Dateideskriptor) und den "Größer" Zeichen stehen, vielleicht ein Grund, dass Du im Log nicht das siehst, was Du sehen willst.
Doch, ist ok. "background" und "anhaengen" sind die beiden Features, die diesem Aufruf mitgegeben werden.
Was meinst Du hier mit "background"?
Ich habe mit dieser Schreibweise (Umleitung von stdout _stderr_ _und_ Anhängen an eine Datei auch schon öfter eigenartiges Verhalten beobachtet, versuch es mal mit "./script.sh >> log.txt 2>> log.txt" ... Sollte eigentlich das selbe bewirken, tut es aber wie gesagt zumindest bei der Bash von SuSE nicht immer.
Es ist empfehlenswert noch "2>&1" anzuhaengen, damit auch die Fehlermeldungen in log.txt auftauchen.
Sollte das nicht schon durch "2>> log.txt" bewirkt werden? Freu mich auf Aufflärung ;-) Beste Grüße, Markus
Hallo, Am Tue, 04 Oct 2005, Markus Heidinger schrieb:
Peter Wiersig wrote at Tuesday, October 04, 2005 9:23 AM
aufrufe um alle Meldungen der Befehle des Scripts im Logfile zu haben.
AFAIK Darf hier KEIN Leerzeichen zwischen dem Ampersand (Dateideskriptor) und den "Größer" Zeichen stehen, vielleicht ein Grund, dass Du im Log nicht das siehst, was Du sehen willst.
Ja, das aendert die Bedeutung: dh@slarty[3]: ~ (0)$ f() { echo 'stdout'; echo 'stderr' >&2; } dh@slarty[3]: ~ (0)$ f & >>/dev/null [1] 3279 dh@slarty[3]: ~ (0)$ stdout stderr [1]+ Done f dh@slarty[3]: ~ (0)$ $ f &>>/dev/null bash: syntax error near unexpected token `&>>/' dh@slarty[3]: ~ (258)$ f >>/dev/null 2>&1 dh@slarty[3]: ~ (0)$
Doch, ist ok. "background" und "anhaengen" sind die beiden Features, die diesem Aufruf mitgegeben werden.
Was meinst Du hier mit "background"?
Dass das script im Hintergrund laeuft, vgl. programm & Korrekt mit Ausgabeumleitung(en) geht's so: dh@slarty[3]: ~ (0)$ f >>/dev/null 2>&1 & [1] 3280 [1]+ Done f >>/dev/null 2>&1 dh@slarty[3]: ~ (0)$ D.h. das '&' um das Programm in den Hintergrund zu schicken kommt als letztes.
Ich habe mit dieser Schreibweise (Umleitung von stdout _stderr_ _und_ Anhängen an eine Datei auch schon öfter eigenartiges Verhalten beobachtet, versuch es mal mit "./script.sh >> log.txt 2>> log.txt" ... Sollte eigentlich das selbe bewirken, tut es aber wie gesagt zumindest bei der Bash von SuSE nicht immer.
Es ist empfehlenswert noch "2>&1" anzuhaengen, damit auch die Fehlermeldungen in log.txt auftauchen.
Sollte das nicht schon durch "2>> log.txt" bewirkt werden?
Geht auch. f >>log.txt 2>>log.txt & ist aequivalent zu f >>log.txt 2>>1 & Die Variante im script mit exec 1>>log.txt exec 2>>log.txt ist aber IMHO auch gut geeignet (siehe man bash | less '+/^redirection'). Ausserdem gibt's in der FAQ einen Artikel: http://suse-linux-faq.koehntopp.de/q/q-shell-redirect.html Und selflinux.de hat auch eine recht gute Einfuehrung in die Shell-Programmierung. -dnh -- "Bitte nennen sie die Art des medizinischen Notfalls!" -- the doc "Ich habe ein Date" -- 7of9
David Haller wrote at Tuesday, October 04, 2005 10:04 AM
AFAIK Darf hier KEIN Leerzeichen zwischen dem Ampersand (Dateideskriptor) und den "Größer" Zeichen stehen, vielleicht ein Grund, dass Du im Log nicht das siehst, was Du sehen willst.
Ja, das aendert die Bedeutung:
dh@slarty[3]: ~ (0)$ f() { echo 'stdout'; echo 'stderr' >&2; } dh@slarty[3]: ~ (0)$ f & >>/dev/null [1] 3279 dh@slarty[3]: ~ (0)$ stdout stderr
[1]+ Done f dh@slarty[3]: ~ (0)$ $ f &>>/dev/null bash: syntax error near unexpected token `&>>/' dh@slarty[3]: ~ (258)$ f >>/dev/null 2>&1 dh@slarty[3]: ~ (0)$
So hab ich das auch gesehen ...
Doch, ist ok. "background" und "anhaengen" sind die beiden Features, die diesem Aufruf mitgegeben werden.
Was meinst Du hier mit "background"?
Dass das script im Hintergrund laeuft, vgl.
programm &
Korrekt mit Ausgabeumleitung(en) geht's so:
dh@slarty[3]: ~ (0)$ f >>/dev/null 2>&1 & [1] 3280 [1]+ Done f >>/dev/null 2>&1 dh@slarty[3]: ~ (0)$
D.h. das '&' um das Programm in den Hintergrund zu schicken kommt als letztes.
OK, mit background in diesem Kontext hab ich das "&" in dem Fall gar nicht gesehen, eben weil es ganz wo anders stand ...
Es ist empfehlenswert noch "2>&1" anzuhaengen, damit auch die Fehlermeldungen in log.txt auftauchen.
Sollte das nicht schon durch "2>> log.txt" bewirkt werden?
Geht auch.
f >>log.txt 2>>log.txt &
ist aequivalent zu
f >>log.txt 2>>1 &
Die Variante im script mit
exec 1>>log.txt exec 2>>log.txt
ist aber IMHO auch gut geeignet (siehe man bash | less '+/^redirection').
Das war jetzt dann doch die perfekte Zusammenfassung, in dem Fall war ich ja dann mal wirklich auf dem _richtigen_ Dampfer ;-) Grüße, Markus
Hallo, Am Tue, 04 Oct 2005, Markus Heidinger schrieb:
David Haller wrote at Tuesday, October 04, 2005 10:04 AM [..]
Geht auch.
f >>log.txt 2>>log.txt &
ist aequivalent zu
f >>log.txt 2>>1 & ^^ *UUPS* Das ist falsch so ;(
f >>log.txt 2>&1 & ^^ hier muss natuerlich wie ueblich fd2 auf fd1 umgebogen werden! [..]
Das war jetzt dann doch die perfekte Zusammenfassung,
Danke. Solltest du so oder so aehnlich auch bei den genannten Dokumenten finden (zumindest in der FAQ und bei Thomas Hertweck). -dnh -- 175: NT-Admin Turnschuhe, Schweissfüsse Weiß, wo der Computer angeht und daß man Probleme durch Neustart, Neuinstallation oder Neubelegung eines 4000-DM-Kurses in Unterschleißheim lösen kann. (Anders Henke)
David Haller wrote at Tuesday, October 04, 2005 2:34 PM
f >>log.txt 2>>1 & ^^ *UUPS* Das ist falsch so ;(
f >>log.txt 2>&1 & ^^ hier muss natuerlich wie ueblich fd2 auf fd1 umgebogen werden!
Fehler passieren ;-)
[..]
Das war jetzt dann doch die perfekte Zusammenfassung,
Danke. Solltest du so oder so aehnlich auch bei den genannten Dokumenten finden (zumindest in der FAQ und bei Thomas Hertweck).
Die ursprüngliche Fragestellung war ohnehin nicht von mir, auf Thomas Hertweck hab ich dann auch in meinem ersten Posting hingewiesen. Markus
Also mal vielen Dank an Alle, ich hab das aufmerksam gelesen und einiges gelernt dabei. Funktioniert hat bereits, wie ihr schon angenommen habt Kommando >> log.txt 2>>log.txt lg Martin
On Tue, Oct 04, 2005 at 09:33:59AM +0200, Markus Heidinger wrote:
Peter Wiersig wrote at Tuesday, October 04, 2005 9:23 AM
Also entweder bin ich gerade dabei, dazu zu lernen (was ja positiv ist) oder ich bin einfach verwirrt ...
Ich auch. Die Notation "&>" war mir neu.
Doch, ist ok. "background" und "anhaengen" sind die beiden Features, die diesem Aufruf mitgegeben werden.
Was meinst Du hier mit "background"?
Wenn du schreibst "foo &" dann wird der Befehl im Hintergrund ausgefuehrt. Das gleiche erreicht man auch mit "Strg-Z" und bg.
Sollte das nicht schon durch "2>> log.txt" bewirkt werden?
Ehrlich gesagt habe ich nie probiert 2 Streams auf deine Art in eine Datei umzuleiten. Die Schreibweise "foo >out 2>&1" oder "foo &> out" sind mir da lieber. Peter
Peter Wiersig wrote at Tuesday, October 04, 2005 11:07 AM Hallo,
Also entweder bin ich gerade dabei, dazu zu lernen (was ja positiv ist) oder ich bin einfach verwirrt ...
Ich auch. Die Notation "&>" war mir neu.
Doch, ist ok. "background" und "anhaengen" sind die beiden Features, die diesem Aufruf mitgegeben werden.
Was meinst Du hier mit "background"?
Wenn du schreibst "foo &" dann wird der Befehl im Hintergrund ausgefuehrt. Das gleiche erreicht man auch mit "Strg-Z" und bg.
Hmm ... Ich glaube aber, dass mit dem von Martin beschriebenen Kommando "./script.sh & >> log.txt" etwas anderes gemeint war ... Zur Aufklärung: Grundsätzlich bedeutet script.sh &> log.txt, das stdout _und_ stderr nach log.txt umgeleitet werden. "&" meint in diesem fall also die file descriptors "1" für stdout und "2" für stdin. 2 Möglichkeiten: Ausgabeumleitung beider Ausgaben, wie oben beschrieben, dann müßte es ./script.sh &>> log.txt heissen, definitiv ohne das Leerzeichen. Dasselbe sollte ./script.sh >> log.txt 2>> log.txt Bewirken, ersteres funktioniert aber wie beschrieben nicht immer. Der Ampersand für stdout und stderr ist im von mir erwähnten Link http://www.thomashertweck.de/redir.html beschrieben. Wollte er noch das mit dem Background dazu haben, dann gehört der Ampersand ganz ans Ende: ./script.sh >> log.txt 2>> log.txt & Dort, wo er bei Martin steht, kann er IMHO nichts mit Background zu tun haben sondern mit der Umleitung beider Ausgabeströme.
Sollte das nicht schon durch "2>> log.txt" bewirkt werden?
Ehrlich gesagt habe ich nie probiert 2 Streams auf deine Art in eine Datei umzuleiten. Die Schreibweise "foo >out 2>&1" oder "foo &> out" sind mir da lieber.
Wie gesagt, das Problem ist, dass "foo &>> out" nicht funktioniert. In diesem Fall also funktioniert Deine erste Variante oder die meinige oben ;-) Hoffe, die Verwirrung ist nun etwas weniger geworden, auch wenn wir noch nicht genau wissen, was Martin mit seinem Kommando gemeint hat ;-) Grüße, Markus
participants (4)
-
David Haller -
Markus Heidinger -
Martin Hochreiter -
Peter Wiersig