Bug in wget 1.7 prev init.c: wgetrc environment var
In wget 1.7 and 1.6, if the WGETRC environment variable is set but the file
specified is inaccessible, the message:
wget: (null): No such file or directory.
is displayed and the program exits with status 1.
Debugging traces the problem to the following function in init.c (ca. line
261)
/* Return the path to the user's .wgetrc. This is either the value of
`WGETRC' environment variable, or `$HOME/.wgetrc'.
If the `WGETRC' variable exists but the file does not exist, the
function will exit(). */
static char *
wgetrc_file_name (void)
{
char *env, *home;
char *file = NULL;
/* Try the environment. */
env = getenv (WGETRC);
if (env *env)
{
if (!file_exists_p (env))
{
fprintf (stderr, %s: %s: %s.\n, exec_name, file, strerror
(errno));
exit (1);
}
return xstrdup (env);
}
where the error message is printed
Firstly, file is a null pointer at the time that this error message is
printed; env is the correct pointer to use here. Secondly, there is no
explanation of why the program is looking for this file.
A possible fix is as follows:
278c278
fprintf (stderr, %s: Unable to access WGETRC specified in
environment: %s: %s.\n, exec_name, env, strerror (errno));
---
fprintf (stderr, %s: %s: %s.\n, exec_name, file, strerror
(errno));
the resultant output is now (when WGETRC is set to c:\.wgetrc, and this file
doesn't exist):
wget: Unable to access WGETRC specified in environment: c:\.wgetrc: No such
file
or directory.
Note: debugging and patching was done with version 1.6 source. I have
upgraded my executable to 1.7 and the bug still exists, but I haven't
obtained the source code to see if there are any changes in this function
between ver 1.6 and 1.7.
Warm Regards,
Chris
Bug in wget 1.7
Hello. I have discovered a bug in wget 1.7 When I try to get thist page: http://www.lehele.de/ this error occurs: - wget -d -r -l 1 www.lehele.de DEBUG output created by Wget 1.7 on linux-gnu. parseurl (www.lehele.de) - host www.lehele.de - opath - dir - file - ndir newpath: / Checking for www.lehele.de in host_name_address_map. Checking for www.lehele.de in host_slave_master_map. First time I hear about www.lehele.de by that name; looking it up. Caching www.lehele.de - 212.227.118.88 Checking again for www.lehele.de in host_slave_master_map. --19:59:51-- http://www.lehele.de/ = `www.lehele.de/index.html' Verbindungsaufbau zu www.lehele.de:80... Found www.lehele.de in host_name_address_map: 212.227.118.88 Created fd 3. verbunden! ---request begin--- GET / HTTP/1.0 User-Agent: Wget/1.7 Host: www.lehele.de Accept: */* Connection: Keep-Alive ---request end--- HTTP Anforderung gesendet, auf Antwort wird gewartet... HTTP/1.1 200 OK Date: Wed, 03 Oct 2001 18:03:52 GMT Server: Apache/1.3.14 (Unix) Connection: close Content-Type: text/html Länge: nicht spezifiziert [text/html] 0K ...@ 332.21 B/s Closing fd 3 20:00:15 (332.21 B/s) - »www.lehele.de/index.html« gespeichert [3830] parseurl (www.lehele.de) - host www.lehele.de - opath - dir - file - ndir newpath: / Loaded www.lehele.de/index.html (size 3830). Speicherzugriffsfehler (core dumped) The file index.html is saved an complete in directory www.lehele.de. If I call wget without recursion then everything is ok, but when i try to go deeper wget is crashing. -Thomas
Re: Size bug in wget-1.7
On 17 Aug 2001, at 11:41, Dave Turner wrote: On Fri, 17 Aug 2001, Dave Turner wrote: By way of a hack I have used the SIZE command, not supported by RFC959 but still accepted by many of the servers I use, to get the size of the file. If that fails then it falls back on the old method. The patch is attached, in what I hope is an acceptable format. Guess who forgot the attachment? Sorry! Nice patch. I think it can be improved by only sending the SIZE command if the file already exists (has a non-zero size, i.e. restval parameter in function getftp is non-zero). I have attached a slightly modified version of Dave Turner [EMAIL PROTECTED]' s patch to add the non-zero restval test, remove an unused variable 's' from function ftp_size, and I have created the patch using the command cvs diff -uR to make it relative to the current CVS sources for wget-1.7.1-pre1. Here is a ChangeLog entry for it: 2001-08-21 Dave Turner [EMAIL PROTECTED] * ftp-basic.c (ftp_size): New function to send non-standard SIZE command to server to request file size. * ftp.h (ftp_size): Export it. * ftp.c (getftp): Use new ftp_size function if restoring transfer of a file with unknown size. wget-1.7.1-pre1-size-fix.patch
Size bug in wget-1.7
Not sure if this is wget's fault or a broken server, but it happens on a lot of servers so maybe it should be handled better. The bug seems to manifest itself when resuming an FTP transfter and the length is unauthoritative. The reported total length is in fact the remaining length (i.e. the total length minus the length downloaded); the reported remaining length is the total length minus twice the length downloaded, which goes negative once you've downloaded 50% of the file! For example, the actual size of kdebase-2.2.tar.bz2 is 10917131 bytes, and this is what my log says when the transfer was resumed at 56%: --11:38:44-- ftp://ftp.sourceforge.net/pub/mirrors/kde/stable/2.2/src/kdebase-2.2.tar.bz2 = `kdebase-2.2.tar.bz2' Connecting to ftp.sourceforge.net:21... connected! Logging in as anonymous ... Logged in! == SYST ... done.== PWD ... done. == TYPE I ... done. == CWD /pub/mirrors/kde/stable/2.2/src ... done. == PORT ... done.== REST 6131968 ... done. == RETR kdebase-2.2.tar.bz2 ... done. Length: 4,785,163 [-1,346,805 to go] (unauthoritative) [ skipping 5760K ] 5760K 131% @ 2.07 KB/s As an artefact of this bug, the percentage downloaded is also incorrect (also shown here) Yours, Dave Turner [EMAIL PROTECTED]
bug in wget-1.7/doc/Makefile.in
hi, guess there is a bug in the Makefile.in of the doc directory the wget.1 couldn't be found if --srcdir option is used ... regards michael 8- / diff doc/Makefile.in doc/Makefile.in_new 118c118 $(INSTALL_DATA) $(srcdir)/$(MAN) $(DESTDIR)$(mandir)/man$(manext)/$(MAN) --- $(INSTALL_DATA) $(MAN) $(DESTDIR)$(mandir)/man$(manext)/$(MAN)
