Re: Minor typo in doc/wget.texinfo on wget 1.9.1

2004-02-08 Thread Hrvoje Niksic
I've now installed this fix, thanks.



Re: skip robots

2004-02-08 Thread Hrvoje Niksic
Jens Rösner [EMAIL PROTECTED] writes:

 Hi Hrvoje!

  PS: One note to the manual editor(s?): The -e switch could be
  (briefly?) mentioned also at the wgetrc commands paragraph. I
  think it would make sense to mention it there again without
  clustering the manual too much. Currently it is only mentioned in
  Basic Startup Options (and in an example dealing with robots).
  Opinions?
 
 Sure, why not.  Have you just volunteered to write the patch?  :-)
 
 Touché!
 ;)
 Well, seriously, I don't know how to write a patch!
[...]
 Or someone sends me a link that explains patching so that even a Windowser 
 can do it ;)

It's really not hard.  To create a patch, you only need the `diff'
utility (available precompiled for Windows).  Save the original copy
of the file, make your change, run `diff -u OLDFILE NEWFILE', and mail
the output here.  That's it.

The file you need to look at to make a change in the documentation is
doc/wget.texi in Wget's distribution.  Although the markup might not
be familiar to you, it is very easy to pick up if you're making a
small change.

In other words, save a copy of wget.texi, make the change, and send the
output of `diff -u wget.texi.orig wget.texi'.  That's it.


This is explained in more detail in the PATCHES file in the Wget
distribution.  See
http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/wget/PATCHES?rev=1.5



Re: skip robots

2004-02-08 Thread Jens Rösner
Hi Hrvoje!

 In other words, save a copy of wget.texi, make the change, and send the
 output of `diff -u wget.texi.orig wget.texi'.  That's it.

Uhm, ok. 
I found diff for windows among other GNU utilities at
http://unxutils.sourceforge.net/
if someone is interested.

 distribution.  See
 http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/wget/PATCHES?rev=1.5

Thanks, I tried to understand that. Let's see if I understood it.
Sorry if I am not sending this to the patches list, the document above 
says that it is ok to evaluate the patch with the general list.

CU
Jens


Patch sum up:
a) Tell users how to --execute more than one wgetrc command
b) Tell about and link to --execute when explaining wgetrc commands.
Reason: Better understanding and navigating the manual.

ChangeLog entry:
Changed wget.texi concerning --execute switch to facilitate 
use and user navigation.

Start patch:


409,410c409,412
 @emph{after} the commands in @file{.wgetrc}, thus taking precedence over
 them.
---
 @emph{after} the commands in @file{.wgetrc}, thus taking precedence over 
 them. If you need to use more than one wgetrc command in your
 command-line, use -e preceeding each.
 
2150,2151c2152,2154
 Most of these commands have command-line equivalents (@pxref{Invoking}),
 though some of the more obscure or rarely used ones do not.
---
 Most of these commands have command-line equivalents (@pxref{Invoking}).
Any
 wgetrc command can be used in the command-line by using the -e (--execute)
(@pxref{Basic Startup Options}) switch.
 


-- 
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: skip robots

2004-02-08 Thread Hrvoje Niksic
Jens Rösner [EMAIL PROTECTED] writes:

 distribution.  See
 http://cvs.sunsite.dk/viewcvs.cgi/*checkout*/wget/PATCHES?rev=1.5

 Thanks, I tried to understand that. Let's see if I understood it.

You're close.  You forgot the `-u' option to diff (very important),
and you snipped the beginning of the `patch' output (also important).



Re: Startup delay on Windows

2004-02-08 Thread Hrvoje Niksic
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: skip robots

2004-02-08 Thread Jens Rösner
 You're close.  You forgot the `-u' option to diff (very important),
 and you snipped the beginning of the `patch' output (also important).

Ok, I forgot the -u switch which was stupid as I actually read 
the command line in the patches file :(
But concerning the snipping I just did 
diff   file.txt 
so I cannot have snipped anything. Is my shell (win2000) 
doing something wrongly or is the missing bit there now (when using the -u
switch).

Jens

Once more:

Patch sum up:
a) Tell users how to --execute more than one wgetrc command
b) Tell about and link to --execute when listing wgetrc commands.
Reason: Better understanding and navigating the manual

ChangeLog entry:
Changed wget.texi concerning --execute switch to facilitate 
use and user navigation.

Start patch:

--- wget.texi   Sun Nov 09 00:46:32 2003
+++ wget_mod.texi   Sun Feb 08 20:46:07 2004
@@ -406,8 +406,10 @@
 @itemx --execute @var{command}
 Execute @var{command} as if it were a part of @file{.wgetrc}
 (@pxref{Startup File}).  A command thus invoked will be executed
[EMAIL PROTECTED] the commands in @file{.wgetrc}, thus taking precedence over
-them.
[EMAIL PROTECTED] the commands in @file{.wgetrc}, thus taking precedence over 
+them. If you need to use more than one wgetrc command in your
+command-line, use -e preceeding each.
+
 @end table
 
 @node Logging and Input File Options, Download Options, Basic Startup
Options, Invoking
@@ -2147,8 +2149,9 @@
 integer, or @samp{inf} for infinity, where appropriate.  @var{string}
 values can be any non-empty string.
 
-Most of these commands have command-line equivalents (@pxref{Invoking}),
-though some of the more obscure or rarely used ones do not.
+Most of these commands have command-line equivalents (@pxref{Invoking}).
Any
+wgetrc command can be used in the command-line by using the -e (--execute)
(@pxref{Basic Startup Options}) switch.
+
 
 @table @asis
 @item accept/reject = @var{string} 






-- 
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

2004-02-08 Thread Jens Rösner
[...]
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

2004-02-08 Thread Fred Holmes
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

2004-02-08 Thread David Fritz
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

2004-02-08 Thread Tony Lewis
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



[PATCH] MSVC Makefiles

2004-02-08 Thread David Fritz
Attached is a patch for the MSVC Makefiles.  I have tested it with MSVC 6.0sp5
for 80x86 and MSVC 7.1 for 80x86 under Windows 2000.
One change of note: I changed the Makefile to use batch rules. This
significantly decreases the time required to build. It might not be supported by
ancient versions of nmake.exe, I don't know.
I'm hoping others can test these changes, especially with older versions of MSVC.

Cheers,
David Fritz
2004-02-09  David Fritz  [EMAIL PROTECTED]

	* configure.bat.in: Don't clear the screen.

* windows/README: Add introductory paragraph.  Re-word a few
sentences.  Correct minor typographical errors.  Use consistent
capitalization of Wget, SSL, and OpenSSL.  Refer to Microsoft
Visual C++ as MSVC instead of VC++.  Mention the --msvc option to
configure.bat.  Reflow paragraphs.
* windows/Makefile.top: Use tabs instead of spaces.  Ignore errors
in clean rules.  Use lowercase filenames when building distribution
.zip archive.
* windows/Makefile.doc: Use tabs instead of spaces.  Ignore errors
in clean rules.
* windows/Makefile.src: Clean-up clean rules.  Use tabs instead of
spaces.  Link against gdi32.lib.  Don't define SYSTEM_WGETRC.
Remove unused macros.  Remove anachronistic and superfluous linker
flags.  Don't rename wget.exe to all upper-case.  Add
`preprocessor' conditionals for SSL and newer MSVC options.  Use
batch rules.  Don't suppress all warnings.



Index: configure.bat.in
===
RCS file: /pack/anoncvs/wget/configure.bat.in,v
retrieving revision 1.4
diff -u -r1.4 configure.bat.in
--- configure.bat.in2003/10/26 00:19:04 1.4
+++ configure.bat.in2004/02/09 05:29:50
@@ -26,7 +26,6 @@
 rem file, but you are not obligated to do so.  If you do not wish to do
 rem so, delete this exception statement from your version.
 
-cls
 if .%1 == .--borland goto :borland
 if .%1 == .--mingw goto :mingw
 if .%1 == .--msvc goto :msvc
Index: windows/Makefile.doc
===
RCS file: /pack/anoncvs/wget/windows/Makefile.doc,v
retrieving revision 1.4
diff -u -r1.4 Makefile.doc
--- windows/Makefile.doc2002/05/18 02:16:35 1.4
+++ windows/Makefile.doc2004/02/09 05:29:51
@@ -28,22 +28,22 @@
 # You probably need makeinfo and perl, see the README in the main
 # windows directory.
 
-RM = del
-CP = copy
-ATTRIB = attrib
-
-MAKEINFO = makeinfo.exe
-TEXI2POD = texi2pod.pl
-POD2MAN  = pod2man
-
-SAMPLERCTEXI = sample.wgetrc.munged_for_texi_inclusion
-WGETHLP  = wget.hlp
-WGETINFO = wget.info
-WGETTEXI = wget.texi
-WGETHTML = wget.html
-WGETPOD  = wget.pod
-manext   = 1
-MAN  = wget.$(manext)
+RM = -del
+CP = copy
+ATTRIB = attrib
+
+MAKEINFO   = makeinfo.exe
+TEXI2POD   = texi2pod.pl
+POD2MAN= pod2man
+
+SAMPLERCTEXI   = sample.wgetrc.munged_for_texi_inclusion
+WGETHLP= wget.hlp
+WGETINFO   = wget.info
+WGETTEXI   = wget.texi
+WGETHTML   = wget.html
+WGETPOD= wget.pod
+manext = 1
+MAN= wget.$(manext)
 
 all: $(WGETHLP) $(WGETINFO) $(WGETHTML)
 
@@ -76,10 +76,10 @@
 hcrtf -xn wget.hpj
 
 clean:
-$(RM) *.bak
-$(RM) *.hpj
-$(RM) *.rtf
-$(RM) *.ph
+   $(RM) *.bak
+   $(RM) *.hpj
+   $(RM) *.rtf
+   $(RM) *.ph
$(RM) $(SAMPLERCTEXI)
$(RM) $(MAN)
$(RM) $(TEXI2POD)
Index: windows/Makefile.src
===
RCS file: /pack/anoncvs/wget/windows/Makefile.src,v
retrieving revision 1.21
diff -u -r1.21 Makefile.src
--- windows/Makefile.src2003/11/21 08:48:45 1.21
+++ windows/Makefile.src2004/02/09 05:29:51
@@ -1,4 +1,4 @@
-# Makefile for `wget' utility for MSVC 4.0
+# Makefile for `wget' utility for MSVC
 # Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
@@ -25,44 +25,49 @@
 # file, but you are not obligated to do so.  If you do not wish to do
 # so, delete this exception statement from your version.
 
-#
-# Version: 1.4.4
-#
-
-#Comment these if you don't have openssl available - however https
-#won't work.
-SSLDEFS=   /DHAVE_SSL
-SSLLIBS=   libeay32.lib ssleay32.lib
-SSLSRC =   gen_sslfunc.c
-SSLOBJ =   gen_sslfunc$o
-
-SHELL = command
-
-VPATH   = .
-o   = .obj
-OUTDIR  = .
-
-CC   = cl
-LD   = link
-
-CFLAGS   = /nologo /MT /W0 /O2
-#DEBUGCF  = /DENABLE_DEBUG /Zi /Od #/Fd /FR
-CPPFLAGS = 
-DEFS = /DWINDOWS /D_CONSOLE /DHAVE_CONFIG_H /DSYSTEM_WGETRC=\wgetrc\
-LDFLAGS  = /subsystem:console /incremental:no /warn:3
-#DEBUGLF  = /pdb:wget.pdb /debug /debugtype:cv /map:wget.map /opt:noref
-LIBS = kernel32.lib