-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, perhaps its time to come back to the question of differentiated exit codes from Wget. This may be a 1.12 question, or perhaps a 1.13 question, but at any rate, with 1.11 ready to go out the day, we perhaps have a little more time to discuss it in depth.
I think the easiest question to ask is how Wget should handle failures when only one file has been specified, and recursive-descent isn't specified. Deciding how Wget should handle multiple arguments, or recursiveness, or both together, is somewhat less straightforward. One thing I do feel strongly, is that if Wget has successfully done its job, and an error condition has not occurred, Wget should return zero. In particular, if Wget chooses not to download a file because the local timestamp is still current, or because its size corresponds to that of the remote file, these should result in an exit status of zero. I agree that differentiating between these conditions could be very useful from a scripting standpoint, but in Unix (and most of the rest of the world, for that matter), anything that's not 0 is interpreted as an error. There is a fair amount of room for delineation between various error statuses; for better or worse, there is no such room for success statuses, and it won't be productive to try to work around it by using a few codes from the error space as "other" success conditions. For multi-file fetches, we could choose to have Wget report the "worst" result it encountered out of the batch, but, to be realistic, that is pretty much completely useless to anyone or anything trying to interpret it. The exception would be when using Wget specifically for completely mirroring a site, in which any failure means a problem; but even there, the return status won't be enough to track down the problem (except in cases of temporary failures such as network or server failures). Also, a failure on the first file, preventing further recursion, will be useful to know about. It may be worthwhile, for multi-file downloads, to add an option specifying a file, into which a mapping between each URL and its result is written, so that scripts can meaningfully determine what has happened and what to do about it. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHW1Bg7M8hyUobTrERAqpnAJ0dT49YjHChh6i2uEEDqRo+jQAVKgCbBIUh z2y2+uu3ADCr7zHdv71kdI8= =WAy0 -----END PGP SIGNATURE-----
