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 sense under Windows?
Or, we could forego the foregoing and use the directory the Wget binary is in as $HOME if it is not defined and not use a `system' wgetrc.
There's really many ways we could go with this. I'm unsure which way makes the most sense.
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'd be willing to work on the patch when we decide on the best way to go with it.
