Re: Startup delay on Windows
I'd be content with the following logic:
Don't process a `system' wgetrc. If $HOME is not defined, use the
directory the Wget executable is in as $HOME (what home_dir() returns).
If $HOME/.wgetrc exists, use that; otherwise look for wget.ini in the
directory the executable is in, regardless of $HOME.
We would retain wget.ini support for backward compatibility, and support
.wgetrc for consistency with other platforms and with the handling of
.netrc. This would only break things if people had $HOME defined and it
contained a .wgetrc and they expected the Windows port to ignore it.
As a side-effect, this would also resolve the above issue.
I went ahead and implemented this. I figure at least it will work as an interim
solution.
2004-02-16 David Fritz [EMAIL PROTECTED]
* init.c (home_dir): Use aprintf() instead of xmalloc()/sprintf().
Under Windows, if $HOME is not defined, use the directory that
contains the Wget binary instead of hard-coded `C:\'.
(wgetrc_file_name): Under Windows, look for $HOME/.wgetrc then, if
not found, look for wget.ini in the directory of the Wget binary.
* mswindows.c (ws_mypath): Employ slightly more robust methodology.
Strip trailing path separator.
Index: src/init.c
===
RCS file: /pack/anoncvs/wget/src/init.c,v
retrieving revision 1.91
diff -u -r1.91 init.c
--- src/init.c 2003/12/14 13:35:27 1.91
+++ src/init.c 2004/02/16 15:58:36
@@ -1,5 +1,5 @@
/* Reading/parsing the initialization file.
- Copyright (C) 1995, 1996, 1997, 1998, 2000, 2001, 2003
+ Copyright (C) 1995, 1996, 1997, 1998, 2000, 2001, 2003, 2004
Free Software Foundation, Inc.
This file is part of GNU Wget.
@@ -314,9 +314,9 @@
return NULL;
home = pwd-pw_dir;
#else /* WINDOWS */
- home = C:\\;
- /* Maybe I should grab home_dir from registry, but the best
-that I could get from there is user's Start menu. It sucks! */
+ /* Under Windows, if $HOME isn't defined, use the directory where
+ `wget.exe' resides. */
+ home = ws_mypath ();
#endif /* WINDOWS */
}
@@ -347,27 +347,24 @@
return xstrdup (env);
}
-#ifndef WINDOWS
/* If that failed, try $HOME/.wgetrc. */
home = home_dir ();
if (home)
-{
- file = (char *)xmalloc (strlen (home) + 1 + strlen (.wgetrc) + 1);
- sprintf (file, %s/.wgetrc, home);
-}
+file = aprintf (%s/.wgetrc, home);
xfree_null (home);
-#else /* WINDOWS */
- /* Under Windows, home is (for the purposes of this function) the
- directory where `wget.exe' resides, and `wget.ini' will be used
- as file name. SYSTEM_WGETRC should not be defined under WINDOWS.
-
- It is not as trivial as I assumed, because on 95 argv[0] is full
- path, but on NT you get what you typed in command line. --dbudor */
- home = ws_mypath ();
- if (home)
+
+#ifdef WINDOWS
+ /* Under Windows, if we still haven't found .wgetrc, look for the file
+ `wget.ini' in the directory where `wget.exe' resides; we do this for
+ backward compatibility with previous versions of Wget.
+ SYSTEM_WGETRC should not be defined under WINDOWS. */
+ if (!file || !file_exists_p (file))
{
- file = (char *)xmalloc (strlen (home) + strlen (wget.ini) + 1);
- sprintf (file, %swget.ini, home);
+ xfree_null (file);
+ file = NULL;
+ home = ws_mypath ();
+ if (home)
+ file = aprintf (%s/wget.ini, home);
}
#endif /* WINDOWS */
Index: src/mswindows.c
===
RCS file: /pack/anoncvs/wget/src/mswindows.c,v
retrieving revision 1.22
diff -u -r1.22 mswindows.c
--- src/mswindows.c 2003/11/03 21:57:03 1.22
+++ src/mswindows.c 2004/02/16 15:58:37
@@ -1,5 +1,5 @@
/* mswindows.c -- Windows-specific support
- Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+ Copyright (C) 1995, 1996, 1997, 1998, 2004 Free Software Foundation, Inc.
This file is part of GNU Wget.
@@ -199,22 +199,25 @@
ws_mypath (void)
{
static char *wspathsave = NULL;
- char buffer[MAX_PATH];
- char *ptr;
- if (wspathsave)
+ if (!wspathsave)
{
- return wspathsave;
-}
+ char buf[MAX_PATH + 1];
+ char *p;
+ DWORD len;
+
+ len = GetModuleFileName (GetModuleHandle (NULL), buf, sizeof (buf));
+ if (!len || (len = sizeof (buf)))
+return NULL;
+
+ p = strrchr (buf, PATH_SEPARATOR);
+ if (!p)
+return NULL;
- if (GetModuleFileName (NULL, buffer, MAX_PATH)
- (ptr = strrchr (buffer, PATH_SEPARATOR)) != NULL)
-{
- *(ptr + 1) = '\0';
- wspathsave = xstrdup (buffer);
+ *p = '\0';
+ wspathsave = xstrdup (buf);
}
- else
-wspathsave = NULL;
+
return wspathsave;
}
Re: Startup delay on Windows
Thanks tracing this one. It would never have occurred to me that the file name c:\/foo could cause such a problem. I see two different bugs here: 1. The routine that merges the .netrc file name with the directory name should be made aware of Windows, so that it doesn't append another backslash if a backslash is already present at the end of directory name returned by home_dir. (In fact, the same logic could be applied to slashes following Unix directory names.) 2. home_dir() should really be fixed to return something better than `c:\' unconditionally, as is currently the case. The comment in the source says: home = C:\\; /* Maybe I should grab home_dir from registry, but the best that I could get from there is user's Start menu. It sucks! */ This comment was not written by me, but by (I think) Darko Budor, who wrote the original Windows support. Under Windows 2000 and XP, there have to be better choices of home directory. For instance, Cygwin considers `c:\Documents and Settings\USERNAME' to be the home directory. I wonder if that is reachable through registry... Does anyone have an idea what we should consider the home dir under Windows, and how to find it?
Re: Startup delay on Windows
[...]
Cygwin considers `c:\Documents and Settings\USERNAME' to be the
home directory. I wonder if that is reachable through registry...
Does anyone have an idea what we should consider the home dir under
Windows, and how to find it?
Doesn't this depend on each user's personal preference?
I think most could live with
c:\Documents and Settings\all users (or whatever it is called in each
language)
or the cygwin approach
c:\Documents and Settings\USERNAME
which will be less likely to conflict with security limits on multi-user PCs
I think.
I personally would like to keep everything wget-ish in the directory its exe
is in
and treat that as its home dir.
BTW:
Is this bug connected to the bug under Windows, that saving into another
directory
than wget's starting dir by using the -P (--directory-prefix) option
does not work when switching drives?
wget -r -P C:\temp URL
will save to
.\C3A\temp\*.*
wget -r -P 'C:\temp\' URL
will save to
.\'C3A\temp\'\*.*
wget -r -P C:\temp\ URL
does not work at all ('Missing URL') error
however
wget -r -P ..\temp2\ URL
works like a charme.
CU
Jens
--
GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...)
jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Re: Startup delay on Windows
At 06:23 PM 2/8/2004, Hrvoje Niksic wrote: Does anyone have an idea what we should consider the home dir under Windows, and how to find it? In Windows 2000, if I enter SET at the command prompt, I get a return that is a listing of all of the environment variables that have been established (set). On my machine, part of that listing is as follows. D:\SET snip HOMEDRIVE=D: HOMEPATH=\Documents and Settings\Administrator snip (D: is my boot drive, and therefore my home drive) (SET [variable] = [value] is the command for establishing an environment variable and its value, in Windows and DOS. SET by itself with no argument reports all of the environment variables and their values.) I'm not a real windows programmer, but any windows compiler should be able to get the values of these environment variables on a particular machine. The are generally/often referenced (at least in windows command prompt batch files) as %HOMEDRIVE% and %HOMEPATH%. Other flavors of Windows should be similar, if not the same, but I don't have the means to test any of them. Fred Holmes
Re: Startup delay on Windows
Petr Kadlec wrote: I have traced the problem down to search_netrc() in netrc.c, where the program is trying to find the file using stat(). But as home_dir() returns C:\ on Windows, the filename constructed looks like C:\/.netrc, which is then probably interpreted by Windows as a name of a remote file, so Windows are trying to look around on the network, and continue only after some timeout. I'm curious as to what operating system and compiler you are using. I tried briefly to reproduce this under Windows 2000 with MSVC 7.1 and could not. I would regard this as a bug in the implementation of stat(), not Wget. BTW, this has come up before: http://www.mail-archive.com/[EMAIL PROTECTED]/msg04440.html Hrvoje Niksic wrote: Thanks tracing this one. It would never have occurred to me that the file name c:\/foo could cause such a problem. It really shouldn't; it seems perfectly valid (albeit strange) to me. Though, I guess, it behooves us to work around compiler/library bugs. I see two different bugs here: 1. The routine that merges the .netrc file name with the directory name should be made aware of Windows, so that it doesn't append another backslash if a backslash is already present at the end of directory name returned by home_dir. (In fact, the same logic could be applied to slashes following Unix directory names.) *AFAIK*, Window should only treat two consecutive slashes specially if they are at the beginning of a file name. (Windows might not like more than one slash between a machine and share name, but that's not really relevant.) Otherwise, they should be equivalent to a single slash. All this irrespective of whether the slashes are forward (/) or backward (\). 2. home_dir() should really be fixed to return something better than `c:\' unconditionally, as is currently the case. The comment in the source says: home = C:\\; /* Maybe I should grab home_dir from registry, but the best that I could get from there is user's Start menu. It sucks! */ This comment was not written by me, but by (I think) Darko Budor, who wrote the original Windows support. Under Windows 2000 and XP, there have to be better choices of home directory. For instance, Cygwin considers `c:\Documents and Settings\USERNAME' to be the home directory. From Cygwin's /etc/profile: # Here is how HOME is set, in order of priority, when starting from Windows # 1) From existing HOME in the Windows environment, translated to a Posix path # 2) from /etc/passwd, if there is an entry with a non empty directory field # 3) from HOMEDRIVE/HOMEPATH # 4) / (root) If things were installed normally, Cygwin will consider /home/username to be the users home directory. Under Cygwin / is usually mounted on C:\cygwin, or wherever Cygwin was installed. But Cygwin is very much it's own environment. Already, two of the above methods are unavailable to us (2 and 4). I wonder if that is reachable through registry... Does anyone have an idea what we should consider the home dir under Windows, and how to find it? I imagine there are a number of ways to go about this. As it stands now, if I understand correctly, Wget works like this: When processing .wgetrc under Windows, Wget does the following: If Wget was built with MSVC, it looks for a file called wgetrc in the current directory. This is mildly evil. A comment in init.c includes the following sentence: SYSTEM_WGETRC should not be defined under WINDOWS. Nonetheless, the MSVC Makefile defines SYSTEM_WGETRC as wgetrc. AFAICT, Wget won't do this if it was built with one of the other Windows Makefiles. Wget then processes the users .wgetrc. Under Windows, Wget ignores $HOME and looks for a file called wget.ini in the directory of the Wget binary. Under Windows, if $HOME is defined home_dir() will return that, otherwise it returns `C:\'. Wget uses the directory returned by home_dir() when looking for .netrc and when resolving ~. So currently Wget's behavior is inconsistent, both with its behavior on other platforms, and with itself (the handling of .wgetrc and .netrc). If we wanted to do things the NT way, we could, essentially, treat C:\Documents and Settings\username\Application Data\Wget as HOME and C:\Documents and Settings\All Users\Application Data\Wget as /etc. The above directories are just examples of typical locations; we would, of course, resolve the directories correctly. But then what would we do if $HOME *is* defined? Ignore it? That would seem the `Windows' thing to do. The directories themselves could be resolved using SHGetSpecialFolderPath() or its like. The entry points would have to resolved dynamically as they may not be available on ancient Windows installations. We could then fall-back to the registry or the environment or something else. The user could always define $WGETRC and put .wgetrc anywhere he/she pleased. But what about .netrc? And does resolving ~ even make
Re: Startup delay on Windows
Hrvoje Niksic wrote: Does anyone have an idea what we should consider the home dir under Windows, and how to find it? On Windows 2000 and XP, there are two environment variables that together provide the user's home directory. (It may go back further than that, but I don't have any machines running older OS versions to confirm that.) For example, on my Windows XP machine, I have to following variables: HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Tony Lewis so my home directory is C:\Documents and Settings\Tony Lewis HTH, Tony
