-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gerard wrote: > On Sunday December 09, 2007 at 03:13:32 (PM) Hrvoje Niksic wrote: > >> Gerard <[EMAIL PROTECTED]> writes: >> >>>> 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 disagree. If wget has not downloaded a file, exiting with zero >>> could lead the end user to believe that it had. >> Specifying `-n' means "download if needed". There is no reason to >> report a non-zero exit status if there was no need to perform the >> download. It is simply not an error condition, it is one of the two >> success conditions (the other being download of the new contents). > > I am fully aware of what the '-n' flag is designed to do. The problem is that > there is no elequent way from within a script to determine whether or not wget > did in fact download a newer version of a file. I fail to see what is so hard > to understand regarding this concept. Presently, I am forced to keep mutilple > copies of files in different directories and then using various scripting > techniques, determine if wget downloaded a newer version.
There is nothing hard to understand: we fully appreciate that it is desirable to determine whether or not Wget downloaded a file. The problem is that the exit status is entirely the wrong mechanism by which to communicate this. A command-line programs should only issue a non-zero exit status in the event that there was a "problem". By giving -N, you specifically asked Wget not to download the file if the local copy's still fresh. Wget did what you asked: therefore, it's success. >>> I disagree again. If wget did not download a file, no matter what >>> the reason, then it should not exit with zero. I have written >>> several scripts that utilize wget to download files. Because wget >>> fails to issue a useful code upon completion, I am forced to use >>> hacks to find out what actually transpired. Curl utilizes certain >>> error codes, # 73 for instance, that are quite useful. >> I agree that Wget should allow the caller to find out what happened, >> but I don't think exit codes can be of much use there. For one, they >> don't allow distinction between different "successful" conditions, >> which is a problem in many cases. Also, their meaning is much harder >> to define in presence of multiple downloads (wget URL1 URL2...). > > Again, I disagree. Example: > > 0 All files downloaded successfully > 1 File newer on server - file downloaded > 2 No newer file on server - no file downloaded > > Obviously the error codes would (should) be much more detailed than that. See > the 'curl' exit codes as an example. I have made suggestions regarding just > this matter on their forum and have received positive feedback. 1 and 2 have no useful meaning in the realm we're supposedly discussing now, which is multiple downloads. And, as previously mentioned, they indicate to the parent process that it failed to do its job, which is especially deceptive for your 1 code above. > In the case of multiple downloads, wget should issue a separate code for each > item. That is absolutely impossible. One exit status per process. This is why I suggested a "mapping" file. Another benefit of a mapping file is that we could use our own coding system, including delineation between different types of "success". - -- 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 iD8DBQFHXF557M8hyUobTrERApfrAJ9QxVdlNylIcDJF99vHALqweCPUSACZAaqI txJVY6ZwhAkuuKMiWIUxyTg= =Z1ky -----END PGP SIGNATURE-----
