modification date (time_t = 0 ) until it is finished?? This way the
incomplete file will always be older than the server file, and will be
replaced.
Craig
From: Hrvoje Niksic [EMAIL PROTECTED]
To: Craig Sowadski [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: wget-cvs
Craig Sowadski [EMAIL PROTECTED] writes:
1. I can implement a patch like my original that only uses the
if-modified-since when the last-modified field is excluded from the
head-only request.
Isn't that what your most recent patch implements?
2. Send the if-modified-since request, then get
was
better.
Craig Sowadski
From: Craig Sowadski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: wget-cvs-ifmodsince.patch
Date: Wed, 18 Feb 2004 15:15:48 -0600
I did this to allow a check on the file size as well as the modification
date. Durring the Head
Thanks for the modification, I've now applied the patch to my
workspace and given it some testing. There's one thing I don't quite
understand. Before the patch, Wget's timestamping was based on
analyzing the Last-Modified header, working like this:
1. Send a HEAD request and get the response.
other sugestions???
Craig
From: Hrvoje Niksic [EMAIL PROTECTED]
To: Craig Sowadski [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: wget-cvs-ifmodsince.patch
Date: Wed, 18 Feb 2004 16:01:51 +0100
Thanks for the modification, I've now applied the patch to my
workspace
Craig Sowadski [EMAIL PROTECTED] writes:
Ok, I have attached a new patch that moves the local time into
http_stat. I am also sending this to [EMAIL PROTECTED] for others to
try out. It seems to work great for me.
I was about to apply this patch, but noted a small problem:
+ if
OK,, here is updated
Craig
From: Hrvoje Niksic [EMAIL PROTECTED]
To: Craig Sowadski [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: wget-cvs-ifmodsince.patch
Date: Tue, 17 Feb 2004 16:34:32 +0100
Craig Sowadski [EMAIL PROTECTED] writes:
Ok, I have attached a new
I just noticed one other problem,, tml is never initialized after I moved to
http_struct. This update takes care of it.
Craig
From: Craig Sowadski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: wget-cvs-ifmodsince.patch
Date
the request.
Craig Sowadski [EMAIL PROTECTED]
From: Hrvoje Niksic [EMAIL PROTECTED]
To: Craig Sowadski [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: wget-cvs-ifmodsince.patch
Date: Thu, 12 Feb 2004 19:01:06 +0100
The patch looks good, thanks. You might want to put the local time
Please try generating the debug output, using the `-d' option. That
way we'll see what kind of incorrect response Wget is getting, and
in response to which FTP command.
Roger Binns [EMAIL PROTECTED] writes:
Has anyone compiled wget for Windows CE (I have PocketPC 2002 Phone
Edition)?
Not that I'm aware of. I don't know what kind of software is required
for such compilation.
Note that it is not hard to compile Wget, so if you have a development
environment
Gerald Oskoboiny [EMAIL PROTECTED] writes:
Hi, the man page for wget 1.8.2 says:
-q
--quiet
Turn off Wget's output.
-nv
--non-verbose
Non-verbose output---turn off verbose without being completely
quiet (use -q for that), which means that error messages
This is a bug -- regardless of whether it supports large files or not,
Wget shouldn't crash when dealing with them.
I plan to look into large file support for the next version of Wget.
Hrvoje == Hrvoje Niksic [EMAIL PROTECTED] writes:
Hrvoje Please send bug reports to [EMAIL PROTECTED], or at least make sure
Hrvoje that they don't go only to me.
Yes, but needing a confirmation message over and over has driven me nuts.
Hrvoje Niksic [EMAIL PROTECTED] writes:
What do you think about this patch:
+ if (USLEEP_usec 0) \
+usleep (USLEEP_usec); \
+} while (0)
Could you change this to have proper number conversions?
usleep ((unsigned long)USLEEP_usec);
works
Georg Bauhaus [EMAIL PROTECTED] writes:
Hrvoje Niksic [EMAIL PROTECTED] writes:
What do you think about this patch:
+ if (USLEEP_usec 0) \
+usleep (USLEEP_usec);\
+} while (0)
Could you change this to have proper number
Hrvoje Niksic [EMAIL PROTECTED] writes:
I'm not sure why the above is in any way improper. [...]
It sounds like your usleep function is undeclared. See if compiler
-E reports the declaration of usleep. I can add the cast to work
around the problem, but it should not be required.
Right,
Quoting Hrvoje Niksic ([EMAIL PROTECTED]):
[...]
Thanks, I'll try to backfeed the information into the PR today, so more
people can look at it.
--
j.
Václav Krpec [EMAIL PROTECTED] writes:
$ wget -e ftp_proxy=ftp://192.168.35.1:3128/ ftp://ftp.fit.vutbr.cz/pub/XFree86
/4.3.0/fixes/*
Error in proxy URL ftp://192.168.35.1:3128/: Must be HTTP.
so, it seems that the proxy is not really ftp proxy, but http that
deals with ftp requests as
Jesper Louis Andersen [EMAIL PROTECTED] writes:
There are a couple of problems with this approach. First, we have
from the NetBSD man-page of usleep(3):
The microseconds argument must be less than 1,000,000. This renders
the sleep impossible for other values of opt.wait than 1. NetBSD
Quoting Hrvoje Niksic ([EMAIL PROTECTED]):
Thanks for pointing this out -- I had no idea that some systems don't
allow usleep to sleep for more than a second. Why do they do that?
I do not know. It conforms to XPG4.2, So I expect the limit to be on
other operating systems too.
The latest
Hrvoje Niksic [EMAIL PROTECTED] writes:
The latest source (available in CVS) has a better sleeping function
that uses nanosleep where available, and that handles usleep's
wraparound for long sleeps. But it still can call usleep with values
larger than 1,000,000. I've attached a patch that
Hrvoje Niksic [EMAIL PROTECTED] writes:
May I suggest using sleep(3) instead. It is used in the code in other
places and has the semantics you want.
sleep(3) cannot sleep for less than a second. I like the idea of
being able to specify `--wait 0.5' for Wget to wait for half a
second
Thanks for the patch. A similar fix is already in CVS.
don [EMAIL PROTECTED] writes:
I did not specify the passive option, yet it appears to have been used
anyway Here's a short transcript:
[EMAIL PROTECTED] sim390]$ wget ftp://musicm.mcgill.ca/sim390/sim390dm.zip
--21:05:21-- ftp://musicm.mcgill.ca/sim390/sim390dm.zip
=
Hans Werner Strube [EMAIL PROTECTED] writes:
There is a name clash in src/connect.c for IRIX 6.2: /usr/include/sys/socket.h
contains a #define sa_len ...
Thanks for the report; this is already fixed in CVS (both in the mail
trunk and in the 1.9 branch).
On Sat, Jan 17, 2004 at 03:14:12AM +0100, Hrvoje Niksic wrote:
Thanks. My copy of Wget parses this file correctly -- you can test
this by calling ftp_parse_unix_ls(.listing, 0) from a debugger and
examining the resulting data structure.
I'm a Perl programmer but haven't ventured into the
I'm not sure what might be causing this. Do you see the same behavior
with 1.9.1?
Examining the `.listing' file in question might prove useful.
On Fri, Jan 16, 2004 at 10:49:08PM +0100, Hrvoje Niksic wrote:
I'm not sure what might be causing this. Do you see the same behavior
with 1.9.1?
Debian is shipping with 1.8.1 right now. I'll try installing 1.9.1.
Examining the `.listing' file in question might prove useful.
Here it is:
William McKee [EMAIL PROTECTED] writes:
On Fri, Jan 16, 2004 at 10:49:08PM +0100, Hrvoje Niksic wrote:
I'm not sure what might be causing this. Do you see the same behavior
with 1.9.1?
Debian is shipping with 1.8.1 right now. I'll try installing 1.9.1.
Examining the `.listing' file in
Juergen Schliessmann [EMAIL PROTECTED] writes:
Wget 1.9.1 fails if a http-proxy and the secure https protocol is
used.
Packet sniffing shows that Wget does not initiate a ssl connection
to the proxy but instead connects directly to the target host
(obvious by a DNS-query) then after that
Yes, it should be.
Mark Post
-Original Message-
From: Cui, Byron [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 13, 2004 11:57 AM
To: [EMAIL PROTECTED]
Subject: wget -- ftp with proxy
Hi,
If use ftp through proxy, would the passive-ftp option still be valid?
Thanks.
Byron Cui
On Tue, Jan 13, 2004 at 02:01:47PM +0100, [EMAIL PROTECTED] wrote:
we are trying to upgrade a newer version of wget (1.5.1 - 1.9.1), but
for some reason updating/mirroring of a ftp site is failing with the
new version.
The following part from your example output ...
Resolving
Zhehong Ying [EMAIL PROTECTED] writes:
Then I moved the wget directory (sub-directory bin etc info man
share) into a staging box (AIX 5.1.0.0). There is no gcc installed
in the staging box because we can not install a C compiler in this
box for security.
Then by running bin/wget as a
Kairos [EMAIL PROTECTED] writes:
$ cat wget.exe.stackdump
[...]
What were you doing with Wget when it crashed? Which version of Wget
are you running? Was it compiled for Cygwin or natively for Windows?
Because the URL has special characters in it, surround it in double quotes:
wget
http://quicktake.morningstar.com/Stock/Income10.asp?Country=USASymbol=JNJ;
stocktab=finance
Mark Post
-Original Message-
From: David C. [mailto:[EMAIL PROTECTED]
Sent: Friday, January 09, 2004 2:01 AM
To:
Hello David,
Because the URL has special characters in it, surround it in double quotes:
wget
http://quicktake.morningstar.com/Stock/Income10.asp?Country=USASymbol=JNJ;
stocktab=finance
Ehm, well yes. Maybe I also should had mentioned that.
Downloading mostly should work if surrounding the
On Tue, Dec 09, 2003 at 11:30:54PM +0100, Hrvoje Niksic wrote:
You're not making a mistake, recursive download over FTP proxies is
currently broken.
That is probably the single feature I'd want most. Is there an older
version of wget, where it works (didn't find it in the ChangeLog)?
Or is it
Zitat von Daniel Daboul [EMAIL PROTECTED]:
On Tue, Dec 09, 2003 at 11:30:54PM +0100, Hrvoje Niksic wrote:
You're not making a mistake, recursive download over FTP proxies is
currently broken.
That is probably the single feature I'd want most. Is there an older
version of wget, where it
[ Please keep the bug address in the Cc, unless you explicitly wish to
exclude it. ]
Grant Giddens [EMAIL PROTECTED] writes:
The first thing I tried was:
wget -vr -o bestbuy.log http://www.bestbuy.com
That grabbed a few files, but the main index page basically said
that the site couldn't
Grant Giddens [EMAIL PROTECTED] writes:
I am new to wget and running the windows version
1.9.1 that I downloaded from:
http://xoomer.virgilio.it/hherold/
I am trying to grab the Best Buy site (www.bestbuy.com) and I think
I'm having a problem with cookies. I have tried all sorts of
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
..
released one that we want (most) users to download. Heiko, would you
consider reordering the table so that the 1.9.1 release row comes
first, followed by development version, (optionally) followed by older
versions?
Ha! :-)
Time ago it was
Herold Heiko [EMAIL PROTECTED] writes:
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
..
released one that we want (most) users to download. Heiko, would you
consider reordering the table so that the 1.9.1 release row comes
first, followed by development version, (optionally) followed by
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Hmm. Then how about separating the development snapshots, and older
entries, to a separate page? It seems simpler for there to be only
Yes, ok, I'll do something like that.
Maybe even one single archive with ssl libraries included, although
Herold Heiko [EMAIL PROTECTED] writes:
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Hmm. Then how about separating the development snapshots, and older
entries, to a separate page? It seems simpler for there to be only
Yes, ok, I'll do something like that. Maybe even one single
You're not making a mistake, recursive download over FTP proxies is
currently broken.
it should be rejected.
unlink: No such file or directory
FINISHED --17:19:37--
Downloaded: 0 bytes in 0 files
--- On Mon 12/08, Tony Lewis [EMAIL PROTECTED] wrote:
From: Tony Lewis [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Mon, 8 Dec 2003 07:50:36 -0800
Subject: Re: Wget 1.9 error
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
New info: I found and tried a different version (1.9.1) and it
worked correctly. So it looks like the problem is just with the dev
version (1.9+cvs-dev-200311280902) I was using.
Ah, I see. Heiko's page doesn't make it obvious which version is the
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, December 07, 2003 8:04 AM
Subject: wget Suggestion: ability to scan ports BESIDE #80, (like 443)
Anyway Thanks for WGET!
What's wrong with wget https://www.somesite.com ?
By the way, can you please clarify the intention behind AI_V4MAPPED
and AI_ALL, which configure tests for, but nothing uses?
Tony Lewis [EMAIL PROTECTED] writes:
A patch was recently submitted for this issue. I don't know if
anything has made it into the CVS or not. Hrvoje didn't like its
dependence on long long so it might not have.
The patch uses `long long' without bothering to check whether the
compiler accepts
On Thu, 20 Nov 2003, Hrvoje Niksic wrote:
Maybe we should concentrate on the contents rather than style. :-)
you're right ;-)
i would also suggest renaming configure.in to configure.ac...
Sure. I've never understood the conceptual difference between the two
anyway. I'm already using
Mauro Tortonesi [EMAIL PROTECTED] writes:
hi to hrvoje and all, i am still alive ;-) and i am finally catching
up with the changes you've done at wget ipv6 code. from what i've
seen so far, it seems that you've done a great job (especially on
lookup_host and resolve_bind_address and on the
Maarten Boekhold [EMAIL PROTECTED] writes:
Is there anything obvious here that I'm doing wrong?
Mirroring FTP over proxies is broken in Wget 1.8 and later, sorry.
I'll look into fixing them for 1.10.
Windows MSVC binary at http://xoomer.virgilio.it/hherold
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED]
-- +39-041-5907073 ph
-- +39-041-5907472 fax
-Original Message-
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 2:55 AM
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
To get the stable sources that have this bug fixed, you might want to
check out the head of the wget-1_9 branch in CVS. Heiko, how about
creating a bugfix 1.9 release for Windows?
No problem with that, but wouldn't a dot release be better ?
The problem is that the server replies with login incorrect, which
normally means that authorization has failed and that further retries
would be pointless. Other than having a natural language parser
built-in, Wget cannot know that the authorization is in fact correct,
but that the server
Kempston [EMAIL PROTECTED] writes:
Yeah, i understabd that, but lftp hadles it fine even without
specifying any additional option ;)
But then lftp is hammering servers when real unauthorized entry
occurs, no?
I`m sure you can work something out
Well, I'm satisfied with what Wget does now.
Herold Heiko [EMAIL PROTECTED] writes:
Windows MSVC binary at http://xoomer.virgilio.it/hherold
Thanks. I assume this means that it compiled without a hitch.
Anyone else with a report? Should I release 1.9.1 now?
Herold Heiko [EMAIL PROTECTED] writes:
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
To get the stable sources that have this bug fixed, you might want to
check out the head of the wget-1_9 branch in CVS. Heiko, how about
creating a bugfix 1.9 release for Windows?
No problem with that,
-- Forwarded message --
From: dvanhorn [EMAIL PROTECTED]
To: list for the ballistic helmet heads [EMAIL PROTECTED]
Date: Mon, 03 Nov 2003 14:13:30 -0500
Subject: Re: [ballistichelmet] White House site prevents Iraq material
being archived
Reply-To: list for the ballistic
This is a known bug in Wget 1.9 that has been fixed in the CVS
sources. (See http://wget.sunsite.dk/ for information about the Wget
CVS tree.)
To get the stable sources that have this bug fixed, you might want to
check out the head of the wget-1_9 branch in CVS. Heiko, how about
creating a
[mailto:[EMAIL PROTECTED]
Sent: Sunday, October 26, 2003 9:16 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: wget 1.9 for windows: no debug support?
[EMAIL PROTECTED] writes:
Well, to find out what was happening, I specified -d for the debug
output. The message was: debug
[EMAIL PROTECTED] writes:
Well, to find out what was happening, I specified -d for the debug
output. The message was: debug support not compiled in
[...]
Is this an oversight or does it serve a purpose?
Heiko will know for sure, but it's most likely an oversight. The
Windows config.h.* files
It seems that Apache's fnmatch.h is shadowing the one from libc.
Please remove the former and your build problems should go away.
Windows MSVC binary present at
http://xoomer.virgilio.it/hherold
Attention if you want to compile your own: there still is the
configure.bat.in file - usually in released packages that was renamed
already to configure.bat .
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL
Hi Hrvoje :)
* Hrvoje Niksic [EMAIL PROTECTED] dixit:
I've announced the 1.9 release on freshmeat
Thanks a lot for your work, Hrvoje, and thanks for Wget ;))
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736
http://www.pleyades.net http://raul.pleyades.net/
On Mon, 2003-10-20 at 14:08, Draen Kaar wrote:
Martin Johnson wrote:
Hrvoje Niksic wrote:
1. Perhaps wget should obey the setting of environment variable
FTP_PASSIVE_MODE (NO or YES)?
Do other programs obey that variable? Are its semantics defined
somewhere?
Yes,
war [EMAIL PROTECTED] writes:
Using gcc-3.3.2:
[...]
Thanks for the report. I'll need a few more details, though.
What operating system is this? Does Wget 1.8.2 compile on the same
system?
Slackware 9.0 - Linux 2.4.22
wget-1.8.2 compiles perfectly..
if test wget = gettext; then \
/vapp/bin/install -c -m 644 ./Makefile.in.in \
/app/wget-1.8.2/share/gettext/po/Makefile.in.in; \
else \
: ; \
fi
make[1]: Leaving directory `/home/war/wget-1.8.2/po'
cd doc make
Hmm. It seems that one of the enums is clashing with something on the
system -- I'm betting it's GETALL. I don't know why this never
happened with older versions.
Does it compile if you add the FTP_ prefix to the names of the
constants, both in ftp.h and ftp.c?
Fixes the compile error, but fails at linking stage.
[EMAIL PROTECTED]:~/wget-1.9$ make
cd src make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\/app
/wget-1.9/etc/wgetrc\ -DLOCALEDIR=\/app/wget-1.9/share/locale\'
CFLAGS='-O2 -
Wall -Wno-implicit' LDFLAGS='' LIBS='-lssl -lcrypto
PROTECTED]
Sent: Friday, October 17, 2003 7:18 PM
To: Tony Lewis
Cc: Wget List
Subject: Re: Wget 1.8.2 bug
Tony Lewis [EMAIL PROTECTED] writes:
Hrvoje Niksic wrote:
Incidentally, Wget is not the only browser that has a problem with
that. For me, Mozilla is simply showing the source
Tony Lewis [EMAIL PROTECTED] writes:
Philip Mateescu wrote:
A warning message would be nice when for not so obvious reasons wget
doesn't behave as one would expect.
I don't know if there are other tags that could change wget's behavior
(like -r and meta name=robots do), but if they happen
Patrick Robinson [EMAIL PROTECTED] writes:
would someone be so kind to tell me the exact syntax to tell wget which
extensions it should reject, e.g. mp3 or mpg
-R mp3 should do the trick.
Windows MSVC binary at
http://xoomer.virgilio.it/hherold/
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED]
-- +39-041-5907073 ph
-- +39-041-5907472 fax
-Original Message-
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2003 4:42
??? ?? [EMAIL PROTECTED] writes:
I've seen pages that do that kind of redirections, but Wget seems
to follow them, for me. Do you have an example I could try?
[EMAIL PROTECTED]:~/ /usr/local/bin/wget -U
All.by -np -r -N -nH --header=Accept-Charset: cp1251, windows-1251, win,
Hrvoje Niksic wrote:
Incidentally, Wget is not the only browser that has a problem with
that. For me, Mozilla is simply showing the source of
http://www.minskshop.by/cgi-bin/shop.cgi?id=1cookie=set, because
the returned content-type is text/plain.
On the other hand, Internet Explorer will
Tony Lewis [EMAIL PROTECTED] writes:
Hrvoje Niksic wrote:
Incidentally, Wget is not the only browser that has a problem with
that. For me, Mozilla is simply showing the source of
http://www.minskshop.by/cgi-bin/shop.cgi?id=1cookie=set, because
the returned content-type is text/plain.
On
The HTML of those pages contains the meta-tag
meta name=robots content=noindex,nofollow /
and Wget listened, and only downloaded the first page.
Perhaps Wget should give a warning message that the file contained a
meta-robots tag, so that people aren't quite so dumb-founded.
/a
On Fri, 17 Oct
Thanks!
A warning message would be nice when for not so obvious reasons wget
doesn't behave as one would expect.
I don't know if there are other tags that could change wget's behavior
(like -r and meta name=robots do), but if they happen it would be
useful to have a message.
Thanks again!
Philip Mateescu wrote:
A warning message would be nice when for not so obvious reasons wget
doesn't behave as one would expect.
I don't know if there are other tags that could change wget's behavior
(like -r and meta name=robots do), but if they happen it would be
useful to have a message.
Aaron S. Hawley [EMAIL PROTECTED] writes:
The HTML of those pages contains the meta-tag
meta name=robots content=noindex,nofollow /
and Wget listened, and only downloaded the first page.
Perhaps Wget should give a warning message that the file contained a
meta-robots tag, so that people
In case you're curious, I'm still waiting for a response from the GNU
people.
If I don't hear from them soon, I'll release 1.9 anyway and put it on
a private FTP site. That way there will be a release for Noel to
package for Debian and we can watch the fun as the bug reports start
pouring.
Hrvoje Niksic wrote:
I'm about to release 1.9 today, unless it takes more time to upload it
to ftp.gnu.org.
If there's a serious problem you'd like fixed in 1.9, speak up now or
be silent until 1.9.1. :-)
I thought we were going to turn our attention to 1.10. :-)
Tony Lewis [EMAIL PROTECTED] writes:
Hrvoje Niksic wrote:
I'm about to release 1.9 today, unless it takes more time to upload it
to ftp.gnu.org.
If there's a serious problem you'd like fixed in 1.9, speak up now or
be silent until 1.9.1. :-)
I thought we were going to turn our
On Wednesday 15 of October 2003 12:11, Thomas Lussnig wrote:
Ok this is clear, but than why become the aplication an binary IPv6
enabled one
if the PC have no IPv6 support ?
Because I'm using packages provided by Linux distribution which needs ipv6
because some users are using it.
I thought
Sergey Vasilevsky [EMAIL PROTECTED] writes:
I use wget 1.8.2. When I try recursive download site site.com where
site.com/ first page redirect to site.com/xxx.html that have first
link in the page to site.com/ then Wget download only xxx.html and
stop. Other links from xxx.html not followed!
Thanks for the report. I agree that the current code does not work
for many uses -- that's why IPv6 is still experimental. Mauro
Tortonesi is working on contributing IPv6 support that works better.
For the impending release, I think the workaround you posted makes
sense. Mauro, what do you
This beta includes portability tweaks and minor improvements. Please
test it on as many diverse platforms as possible, preferrably with
both gcc and non-gcc compilers. If all goes well, I'd like to release
1.9 perhaps as early as tomorrow.
Windows, msvc:
host.c
host.c(604) : error C2065:
Herold Heiko [EMAIL PROTECTED] writes:
This beta includes portability tweaks and minor improvements. Please
test it on as many diverse platforms as possible, preferrably with
both gcc and non-gcc compilers. If all goes well, I'd like to release
1.9 perhaps as early as tomorrow.
Windows,
Herold Heiko [EMAIL PROTECTED] writes:
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Does it compile if you change #define HAVE_U_INT32_T 1 to #undef
HAVE_U_INT32_T in config.h.ms?
It does.
Windows msvc binary at http://xoomer.virgilio.it/hherold
Cool. BTW does MSVC have int32_t?
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Does it compile if you change #define HAVE_U_INT32_T 1 to #undef
HAVE_U_INT32_T in config.h.ms?
It does.
Windows msvc binary at http://xoomer.virgilio.it/hherold
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED]
--
, 2003 4:02 PM
To: Herold Heiko
Cc: [EMAIL PROTECTED]
Subject: Re: Wget 1.9-beta5 available for testing
Herold Heiko [EMAIL PROTECTED] writes:
From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
Does it compile if you change #define HAVE_U_INT32_T 1 to #undef
HAVE_U_INT32_T in config.h.ms
Herold Heiko [EMAIL PROTECTED] writes:
C:\Programmi\Microsoft Visual Studio\VC98\Include\Native.h has:
typedef long int32_t;
I see. We're currently not using signed 32-bit variables, so I guess
the point is moot.
On Wed, 8 Oct 2003, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
I still don't understand the choice to use sockaddr and
sockaddr_storage in a application code.
They result in needless casts and (to me) uncomprehensible code.
well, using sockaddr_storage is the right
Mauro Tortonesi [EMAIL PROTECTED] writes:
and i'm saying that for this task the ideal structure is
sockaddr_storage. notice that my code uses sockaddr_storage
(typedef'd as wget_sockaddr) only when dealing with socket
addresses, not for ip address caching.
Now I see. Thanks for clearing it
Wouldn't it be simpler to use
CreateProcess (wget.exe, cmd_line, NULL, NULL, FALSE,
DETACHED_PROCESS, ...)
That flag will automatically hide the process.
Thanks, I'll look into it as a simpler altenative solution. One nice side
effect of wget source recompilation is that I was able to
On Fri, 10 Oct 2003, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
An IPv4 address is nothing more than a 32-bit quantity. I don't
see anything incorrect about using unsigned char[4] for that, and
that works perfectly fine on 64-bit architectures.
ok, but in this way
Forrest Garnett [EMAIL PROTECTED] writes:
We see the enclosed errors attempting to compile the most recent
wget package with aix 4.3.3 and aix 5.1.
Thanks for the report. There are several problems with the
compilation.
For one, all the logprintf() lines are failing. This could come from
701 - 800 of 1221 matches
Mail list logo
