Re: bug in connect.c
Interesting. Is it really necessary to zero out sockaddr/sockaddr_in before using it? I see that some sources do it, and some don't. I was always under the impression that, as long as you fill the relevant members (sin_family, sin_addr, sin_port), other initialization is not necessary. Was I mistaken, or is this something specific to FreeBSD? Do others have experience with this? e.g. look at http://cvs.tartarus.org/putty/unix/uxnet.c putty encountered the very same problem ... regards manfred
Bug in 1.9.1? ftp not following symlinks
hi i tried to download the following: wget ftp://ftp.suse.com/pub/suse/i386/7.3/full-names/src/traceroute-nanog_6.1.1-94.src.rpm this is a symbolic link. downloading just this single file, wget should follow the link, but it creates only a symbolic link. excerpt from "man wget", section --retr-symlinks: Note that when retrieving a file (not a directory) because it was specified on the command-line, rather than because it was recursed to, this option has no effect. Symbolic links are always traversed in this case. but: wget --retr-symlinks ftp://ftp.suse.com/pub/suse/i386/7.3/full-names/src/traceroute-nanog_6.1.1-94.src.rpm does get the file correctly. this occurs only if using "timestamping = on" in wgetrc, without it everything works ok. regards manfred
Re: Translations for 1.9.1
> "Manfred Schwarb" <[EMAIL PROTECTED]> writes: > > > I just installed wget 1.9.1, works fine. But on my machine, > > translations are broken somehow, all special characters are > > scrambled. With wget 1.9 this didn't happen. > > There was no change in handling translation from 1.9 to 1.9.1, except > perhaps for a new `de.po' from the Translation Project. Indeed, the > blunder is theirs: they switched to utf-8 for `de.po', but forgot to > mark it as utf-8. > > They fixed this problem later, so future versions of Wget will not > have this problem. If you want, you can download the latest German PO > file from the Translation Project and correct the problem yourself. > I followed the hint of Gisle and did cat de.po | iconv -f UTF-8 -t ISO-8859-1 > de.po.new; mv de.po.new de.po this worked great. Thanks Manfred -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++
Re: Translations for 1.9.1
> It's normal. de.po is written in UTF-8. > Use e.g > cat de.po | iconv -f UTF-8 -t CP850 > > to display correctly, but gettext should handle this fine. I see. Thanks a lot for your hint. Probably my gettext is just too old. A remark about this issue in the "README" or "INSTALL" file would be great. Manfred -- GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen! Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken tolle Preise. http://www.gmx.net/de/cgi/special/ +++ GMX - die erste Adresse für Mail, Message, More! +++
Re: if anything bad happens, return non-zero
> $ wget --spider BAD_URL GOOD_URL; echo $? > 0 > $ wget --spider GOOD_URL BAD_URL; echo $? > 1 > I say they both should be 1. > If anything bad happens, return 1 or some other non-zero value. I'm glad I'm not the only one to complain about this issue. I wasted a lot of time taiming my downloads just because wget has no proper exit status handling (see my posting about "BUG in --timeout (exit status)") Manfred -- GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen! Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken tolle Preise. http://www.gmx.net/de/cgi/special/ +++ GMX - die erste Adresse für Mail, Message, More! +++
Translations for 1.9.1
Hi, I just installed wget 1.9.1, works fine. But on my machine, translations are broken somehow, all special characters are scrambled. With wget 1.9 this didn't happen. Example from de.po: #: src/convert.c:439 #, c-format msgid "Cannot back up %s as %s: %s\n" msgstr "Anlegen eines Backups von »%s« als »%s« nicht möglich: %s\n" (ftp://ftp.gnu.org/pub/gnu/wget/wget-1.9.1.tar.gz, unpacked on linux with "tar xvfz") Am I the only one with this problem? Manfred PS: I use a different email address now, as since my last posting the amount of spam reached new dimensions. Probably because this list is mirrored as a newsgroup with cleartext email addresses :-( -- GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen! Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken tolle Preise. http://www.gmx.net/de/cgi/special/ +++ GMX - die erste Adresse für Mail, Message, More! +++
Re: BUG in --timeout (exit status)
OK, I see. But I do not agree. And I don't think it is a good idea to treat the first download special. In my opinion, exit status 0 means "everything during the whole retrieval went OK". My prefered solution would be to set the final exit status to the highest exit status of all individual downloads. Of course, retries which are triggered by "--tries" should erase the exit status of the previous attempt. A non-zero exit status does not mean "nothing went OK" but "some individual downloads failed somehow". And setting a non-zero exit status does not mean wget has to stop retrieval immediately, it is OK to continue. Again, wget's behaviour is not what the user expects. And the user has always the possibility to make combinations of --accept, --reject, --domains, etc. so in normal cases all individual downloads succeed, if he needs a exit status 0. If he does not care about exit status, there is no problem at all, of course... regards Manfred Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>: > This problem is not specific to timeouts, but to recursive download (-r). > > When downloading recursively, Wget expects some of the specified > downloads to fail and does not propagate that failure to the code that > sets the exit status. This unfortunately includes the first download, > which should probably be an exception. > This message was sent using IMP, the Internet Messaging Program.
BUG in --timeout (exit status)
Hi, doing the following: # /tmp/wget-1.9-beta3/src/wget -r --timeout=5 --tries=1 http://weather.cod.edu/digatmos/syn/ --11:33:16-- http://weather.cod.edu/digatmos/syn/ => `weather.cod.edu/digatmos/syn/index.html' Resolving weather.cod.edu... 192.203.136.228 Connecting to weather.cod.edu[192.203.136.228]:80... failed: Connection timed out. Giving up. FINISHED --11:33:21-- Downloaded: 0 bytes in 0 files # echo $? 0 If wget aborts because of an timeout (all --*-timeout options), it sets an exit status of 0, which is not what users are expecting, and which makes it very difficult to catch such aborts. Using "--non-verbose" in this example, I get no response at all that something might have failed. An abort has nothing to do with being verbose or not, it should always be notified in some way, IMHO. Further more, wget man and info pages should document the exit status, I could not find any documentation about wget's exit status. In contrast, curl does the right thing (non-zero exit status): # curl -r --connect-timeout 5 http://weather.cod.edu/digatmos/syn/ curl: (7) # echo $? 7 regards Manfred This message was sent using IMP, the Internet Messaging Program.
