[Top][All Lists]
[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/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug-wget] Exit codes,
Micah Cowan <=