Chcę pobrać plik za pomocą Wget , ale zgodnie ze zwykłą filozofią UNIX, nie chcę, aby coś wypisało, jeśli pobieranie się powiedzie. Jednak jeśli pobieranie się nie powiedzie, chcę komunikat o błędzie.
-qOpcja wyłącza wszystkie wyjścia, w tym komunikaty o błędach. Jeśli -nvzamiast tego podam opcję, Wget nadal drukuje (na stderr):
2012-05-03 16:17:05 URL:http://example.net/ [2966] -> "index.html" [1]
Jak mogę usunąć nawet to wyjście, ale nadal otrzymuję komunikaty o błędach?
Odpowiedzi:
Spróbuj curlzamiast tego:
curl -fsS $url -o $file
Długa wersja:
curl --fail --silent --show-error $url --output $file
Użytkownicy GNOME mogą wypróbować Gvfs:
gvfs-cp $url $file
--fail? czy nie ma sensu traktować błędów HTTP jako czegoś, co chciałbyś przejść do stderr?
--faili --show-error.
Kulawy hack, jeśli nie możesz uzyskać lepszej odpowiedzi:
wget {url} 2>/tmp/err.log || cat /tmp/err.log; rm /tmp/err.log
(2> /tmp/err.log przekierowuje stderr do pliku tmp; jeśli wget zwróci 0 [sukces], zwarcie || w przeciwnym razie wydrukuje wartości dziennika błędów)
error_log=$(wget -nv example.net 2>&1) || echo $error_logjest bardziej eleganckim rozwiązaniem, ale wciąż niezdarnym.
Ponieważ obecnie wszystkie dane wyjściowe wget są przesyłane do stderr, wydaje się, że aby rozwiązać ten „elegancki sposób”, musiałbyś załatać źródło wget.
Projekt źródła wget dyktuje różnicę poziomu szczegółowości między komunikatami, zamiast prostego podziału na komunikat o błędzie, a nie o błędzie.
Istnieje otwarty błąd dotyczący tej http://savannah.gnu.org/bugs/?33839 , a także trochę starszej dyskusji. Oto sugerowana łatka http://www.mail-archive.com/wget%40sunsite.dk/msg03289.html i tutaj jest odpowiedź Hrvoje Niksica na temat tego http://www.mail-archive.com/wget % 40sunsite.dk / msg03330.html .
Poza tym istnieje oczywiście dobre rozwiązanie, które zaproponowałeś w komentarzu do mniej eleganckiego rozwiązania Foon.