wget und stderr

[debphp]

hallo community,

ich habe ein kleines problem bzw. eine verständnisfrage.

per cronjob rufe ich ein script über einen webserver auf:

Code: Select all

wget http://example.org/script.php > /dev/null

das funktioniert soweit auch, nur erhalte ich jedesmal eine email, dass das script gelaufen ist.
das wollte ich eigentlich mit der umleitung nach > /dev/null vermeiden. auf der shell erhalte ich bei dem befehl auch eine ausgabe.

wenn ich stderr umleite, also 2> /dev/null funktioniert es.
da stellt sich für mich die frage, warum die ausgabe von wget ein fehler ist :?:

ich hatte es so gedacht, wenn wget erfolgreich - keine mail und wenn wget die seite nicht aufrufen kann, soll eine mail verschickt werden.

[Roger Wilco]

Code: Select all

man wget
wget -q [...]

[debphp]

Code: Select all

man wget
wget -q [...]

ja, danke - damit unterdrückt man die ausgabe vollständig.

aber was mich eigentlich wundert ist folgendes:

Code: Select all

wget http://google.de > /dev/null

damit erhalte ich auf der shell eine ausgabe.

mit:

Code: Select all

wget http://google.de 2> /dev/null

erhalte ich jedoch keine ausgabe.
und 2> bedeutet doch, dass ich den stderr umleite.
soll ich jetzt daraus schließen, dass der wget-aufruf einen fehler erzeugt hat? das ist mir irgendwie unklar.

[hornox]

stdout ist der Ausgabekanal für Nutzdaten, stderr für Fehler und IMHO auch für Statusmeldungen. Wäre ja auch irgendwo fies man die Statusmeldungen aus den Nutzdaten rausfiltern müßte. Wobei ich zugegebernerweise keine Ahnung habe ob wget überhaupt irgendwas auf stdout ausgibt, selbst die Header die man sich mit -S anzeigenlassen kann landen auf sdterr :( Wenn du wissen willst ob der wget-aufruf einen Fehler erzeugt hat kannst du den Rückgabewert überprüfen

Code: Select all

wget ... && echo fehler

[flo]

... wobei wget auch gerne mal 48h läuft, wenn er wirklich auf einen Fehler stösst - das Problem habe ich gerade bei automatisierter Prüfung von Websites - der exit-Code wird eben erst nach dem exit erzeugt. :-(

[aldee]

stdout ist der Ausgabekanal für Nutzdaten, stderr für Fehler und IMHO auch für Statusmeldungen. Wäre ja auch irgendwo fies man die Statusmeldungen aus den Nutzdaten rausfiltern müßte. Wobei ich zugegebernerweise keine Ahnung habe ob wget überhaupt irgendwas auf stdout ausgibt, selbst die Header die man sich mit -S anzeigenlassen kann landen auf sdterr :(

wget -O - url schreibt die Nutzdaten (den Inhalt der angeforderten Datei) nach STDOUT.

... wobei wget auch gerne mal 48h läuft, wenn er wirklich auf einen Fehler stösst - das Problem habe ich gerade bei automatisierter Prüfung von Websites - der exit-Code wird eben erst nach dem exit erzeugt. :-(

wget --timeout?

[flo]

wget --timeout?

Sollte ich an und für sich schon probiert haben ... bin mir nicht sicher, wo bei der betreffenden Domain der Fehler liegt - mal in Ruhe debuggen.

[debphp]

Wenn du wissen willst ob der wget-aufruf einen Fehler erzeugt hat kannst du den Rückgabewert überprüfen

Code: Select all

wget ... && echo fehler

ok, das habe ich mal gemacht und "fehler" wird am ende ausgegeben :(

z.b.

Code: Select all

wget http://www.google.de

bringt folgende ausgabe (mit anderen urls verhält es sich ähnlich):

Code: Select all

--10:15:14--  http://www.google.de/
           => `index.html.5'
Auflösen des Hostnamen »www.google.de«.... 209.85.135.147, 209.85.135.99, 209.85.135.103, ...
Verbindungsaufbau zu www.google.de|209.85.135.147|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: nicht spezifiziert [text/html]

    0K ...                                                       2.41 MB/s

10:15:14 (2.41 MB/s) - »index.html.5« gespeichert [3186]

kann mir mal jemand erklären, was daran ein fehler ist?

[hornox]

Ich kann mich nie dran erinnern das bei der bash 0 true ist :( Mit einem || anstatt einer && funktioniert es:

Code: Select all

hornox:~# wget -q heise.de 2>/dev/null || echo fehler
hornox:~# wget -q heisesfdsfd.de 2>/dev/null || echo fehler
fehler
hornox:~#

[EdRoxter]

IMHO hat HornOx recht. && greift doch genau dann, wenn der Exitcode 0 ist, also alles glatt gelaufen.
Somit wäre semantisch gesehen

Code: Select all

wget http://www.xyz.de && echo "Alles klar!"

richtig. Das mag debphp verwirrt haben..

[floogy]

Soweit ich mich erinnere wird bei erfolgreichem Ausdruck nach && der folgende Befehl in jedem Fall ausgeführt. Bei einem Abbruch durch einen Fehler nicht. Wahrscheinlich also unabhängig von der Fehlerausgabe (? hä).
Für || gilt das gegenteilige Verhalten.

Code: Select all

$ wget google.de 2>/dev/null && echo fehler
fehler
$ wget google.xx 2>/dev/null && echo fehler

$ wget google.de 2>/dev/null || echo fehler
$ wget google.xx 2>/dev/null || echo fehler
fehler

http://de.wikibooks.org/wiki/Linux-Komp ... kgabewerte
http://de.wikibooks.org/wiki/Linux-Komp ... ehlsformen

Code: Select all

Befehl1 && Befehl2     AND, führt zuerst Befehl1 und dann (wenn Befehl1 erfolgreich war) Befehl2 aus    
Befehl1 || Befehl2     OR, entweder Befehl1 ausführen oder Befehl2 (Wenn Befehl1 nicht erfolgreich war)  

Code: Select all

wget http://www.xyz.de 2>/dev/null && echo "Alles klar!"

Stimmt, das macht es klar. ;-)

[floogy]

... wobei wget auch gerne mal 48h läuft, wenn er wirklich auf einen Fehler stösst - das Problem habe ich gerade bei automatisierter Prüfung von Websites - der exit-Code wird eben erst nach dem exit erzeugt. :-(

Vielleicht hilft das hier:

Code: Select all

 --dns-timeout=40  -T 40 -t 1 -w 1

Hmmm... bei 20 retries hängt wget bei Dir 48h?

[daemotron]

Um auf das ursprüngliche Problem noch mal zurückzukommen: Offenbar unterscheiden die Entwickler von wget nicht richtig sauber, ob sie auf STDERR oder STDOUT rausblasen. Für's Scripting gibt's aber einen einfachen Trick, trotzdem zwischen korrekter Ausführung und fehlerhaftem Abbruch zu unterscheiden.

Der korrekte Weg, den Rückgabewert eines Programms auszuwerten, ist bei Bourne-Shell kompatiblen Shells die Variable $?, die den numerischen Rückgabewert des letzten beendeten Prozesses enthält.

Beispiel:

Code: Select all

#!/bin/sh
out=$(/usr/bin/wget "irgendeine-url")
if [ "$?" -ne "0" ]; then
  echo $out >> /var/log/scriptfehler.log
fi

[aldee]

Um auf das ursprüngliche Problem noch mal zurückzukommen: Offenbar unterscheiden die Entwickler von wget nicht richtig sauber, ob sie auf STDERR oder STDOUT rausblasen.

Tun sie doch. Auf STDERR kommen Meta-Informationen und Fehler, auf STDOUT ggf. die Nutzdaten; letztere werden jedoch standardmäßig in eine Datei geschrieben, somit erfolgt per Default keine Ausgabe auf STDOUT. Durch expliziten Aufruf von "wget -O -" kann man aber die Ausgabe auf STDOUT erzwingen.

Edit: Fipptehler.