bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-wget] Exit codes


From: Micah Cowan
Subject: [Bug-wget] Exit codes
Date: Fri, 28 Aug 2009 00:17:33 -0700
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

http://hg.addictivecode.org/wget/mainline/rev/62f8104d1814

New behavior in Wget for returning exit codes, and documentation for it:

...
EXIT STATUS
       Wget may return one of several error codes if it
       encounters problems.

       0   No problems occurred.

       1   Generic error code.

       2   Parse error---for instance, when parsing command-line
           options, the .wgetrc or .netrc...

       3   File I/O error.

       4   Network failure.

       5   SSL verification failure.

       6   Username/password authentication failure.

       7   Protocol errors.

       8   Server issued an error response.

       With the exceptions of 0 and 1, the lower-numbered exit
       codes take precedence over higher-numbered ones, when
       multiple types of errors are encountered.

       In versions of Wget prior to 1.12, Wget’s exit status
       tended to be unhelpful and inconsistent. Recursive
       downloads would virtually always return 0 (success),
       regardless of any issues encountered, and non-recursive
       fetches only returned the status corresponding to the
       most recently-attempted download.
...


This implementation is hardly perfect; and due to the messy ways that
Wget tends to handle result codes, it's probably buggy. Many of its
shortcomings, though, lie in the impracticality of trying to squeeze
useful information about errors into an 8-bit value, and in the fact
that different people care about different problem conditions.

I strongly considered using a bit-mask for the error code, so that Wget
could use it to communicate multiple types of problems in the same
result. I finally decided against this, however, because dealing with
such results could become unweildly in wrapper scripts. But the fact
that most of these errors are not fatal (Wget will continue processing
the other links in its queue) means that only being able to report a
single type of error reduces the value of having the separate error
codes. At some point in the future, we'll want a more detailed
error-reporting facility, that can be used to drill down not only what
sorts of problems occurred, but on what URLs.

Regardless, the major win here is the fact that Wget will actually
report the errors at all. Slurping down a chunk of website and then
having no way of knowing whether it actually got all the files you
wanted was clearly undesirable.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]