Re: Wget 1.11 build fails on old Linux
On Monday, February 25, 2008 at 16:32:21 +0100, Alain Guibert wrote: > On an old Debian Bo system (kernel 2.0.40, gcc 2.7.2.1, libc 5.4.33), > building Wget 1.11 fails: While wget 1.11.1 builds and works OK. Thank you very much, gentlemen! Alain.
Re: Wget 1.11 on a IBM iSeries platform problems No Virus
Micah Cowan <[EMAIL PROTECTED]> writes: > Hrvoje Niksic wrote: >> I agree that clock_getres itself isn't important. Still, Wget needs >> to choose a clock that actually works out of several possible clocks >> allowed by POSIX (and common extensions), so it's advisable to at >> least attempt to use the clock in some way. If clock_getres is known >> to fail on some platforms, then we should use clock_gettime instead. > > Instead? The only time we ever use clock_getres, AFAICT, is when > clock_gettime I referred to the use of clock_getres in posix_init, where it's used to figure out which clock id to use as posix_clock_id. We could use clock_gettime there and completely remove the usage of clock_getres.
Re: Wget 1.11 on a IBM iSeries platform problems No Virus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hrvoje Niksic wrote: > I agree that clock_getres itself isn't important. Still, Wget needs > to choose a clock that actually works out of several possible clocks > allowed by POSIX (and common extensions), so it's advisable to at > least attempt to use the clock in some way. If clock_getres is known > to fail on some platforms, then we should use clock_gettime instead. Instead? The only time we ever use clock_getres, AFAICT, is when clock_gettime tells us zero time has elapsed. We just use clock_getres to find out the clock's resolution, and then use half that, as a midway point for guesstimating the d/l rate for downloads so quick clock_gettime couldn't clock 'em. IOW, the only time we ever use clock_getres is exactly when clock_gettime is of no use (and even clock_getres is of fairly little). > I wonder if clock_gettime works for a clock for which clock_getres > fails. Apparently, it does. Otherwise, I'd have expected OP's d/l rate to have returned nonsense values; but it appears to proceed fine. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHthDG7M8hyUobTrERAvumAJ45LcBNGqsskzNb8PcBcp4jIVRWSgCggA/L vdIIB+v5uVHTH/oFiSr88eY= =X1eA -END PGP SIGNATURE-
Re: Wget 1.11 on a IBM iSeries platform problems No Virus
Micah Cowan <[EMAIL PROTECTED]> writes: >> 2) When I download files from a URL I get the following error: >> >> Cannot get REALTIME clock frequency: Invalid argument > > I can't tell you why that'd happen; Wget falls back to a clock id that > should be guaranteed to exist. An erroneous time.h header would perhaps > explain it. > > The error isn't serious, though, and may safely be ignored. > > In fact: Hrvoje? What do you think about removing that warning > altogether (or, perhaps, increasing the verbosity level required to > issue it)? AFAICT, the clock's resolution is used in only one place, I agree that clock_getres itself isn't important. Still, Wget needs to choose a clock that actually works out of several possible clocks allowed by POSIX (and common extensions), so it's advisable to at least attempt to use the clock in some way. If clock_getres is known to fail on some platforms, then we should use clock_gettime instead. I wonder if clock_gettime works for a clock for which clock_getres fails.
Re: Wget 1.11 on a IBM iSeries platform problems No Virus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Micah Cowan wrote: > [EMAIL PROTECTED] wrote: >> Hello, > >> I have compiled a GNU Wget 1.11 on a IBM iSeries platform. (Host system >> type... powerpc-ibm-os400) >> Well, wget works but I have some problems. > >> 1) I need messages in spanish, but I´ve only in english. > >> How can I compile the program in spanish? >> Or, how can I change the language support to es_ES? > > Wget will automatically configure for building with National Language > Support (NLS), if GNU gettext is installed on your system where Wget's > configure script can find it. See > http://www.gnu.org/software/gettext/gettext.html for how to obtain and > install it. Totally meant, but forgot, to mention: Once you're sure Wget has been built and installed with NLS support, you'll want to ensure that your environment has something like "LANG=es_ES.UTF-8" or something similarly appropriate. But I'm guessing you already have this sort of things set up for your system? - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHtLrI7M8hyUobTrERAmP9AJ4ififmOtiB6G/5B+bcY1FmxkYyBQCfaoWf Jz1HWprruEGu+ngZcAKAzBM= =VeT4 -END PGP SIGNATURE-
Re: Wget 1.11 on a IBM iSeries platform problems No Virus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: > > Hello, > > I have compiled a GNU Wget 1.11 on a IBM iSeries platform. (Host system > type... powerpc-ibm-os400) > Well, wget works but I have some problems. > > 1) I need messages in spanish, but I´ve only in english. > > How can I compile the program in spanish? > Or, how can I change the language support to es_ES? Wget will automatically configure for building with National Language Support (NLS), if GNU gettext is installed on your system where Wget's configure script can find it. See http://www.gnu.org/software/gettext/gettext.html for how to obtain and install it. If it is installed correctly, the output from configure should include something like: checking whether NLS is requested... yes configure: language catalogs: be bg ca cs da de el en_GB eo es et eu fi fr ga gl he hr hu id it ja nb nl pl pt pt_BR ro ru sk sl sr sv tr uk vi zh_CN zh_TW checking for msgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for gmsgfmt... /usr/bin/msgfmt checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for gettext in -lintl... no checking for gettext... yes > 2) When I download files from a URL I get the following error: > > Cannot get REALTIME clock frequency: Invalid argument I can't tell you why that'd happen; Wget falls back to a clock id that should be guaranteed to exist. An erroneous time.h header would perhaps explain it. The error isn't serious, though, and may safely be ignored. In fact: Hrvoje? What do you think about removing that warning altogether (or, perhaps, increasing the verbosity level required to issue it)? AFAICT, the clock's resolution is used in only one place, in retr.c's calc_rate function, which uses it only to come up with a guess, when a download has taken what the timer reports as "zero seconds". In other words, it's almost unnecessary. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHtI3X7M8hyUobTrERAgc2AJ987JCCPq0NSl5Ts+5k75Q78EZfPwCcDuoA +YvELduPVMiKbQwdFMFkRUg= =h7HV -END PGP SIGNATURE-
Re: wget 1.11 no-clobber still sending GET request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles wrote: > Hi, > > Comparing the behavior of wget 1.11 and wget 1.10, in wget 1.11 using > wget -nc url still sends a GET request to the server while this does > not happen is wget 1.10. > > My question is how do I turn off this behavior? > > Looking at the code in http.c I do not see any flag to turn off the > creation of a new request (in line 1434). Hi Charles, TBH, I don't understand the relevant code in http.c nearly as well as I'd like. It's not one flag to turn it off, but several various checks at different points, I believe. My current goal for the 1.12 codebase is to get this area cleaned up to the point that I can navigate it with less trouble than I currently must. :) I'll investigate the regression; however, I can't promise to fix it for 1.11.1. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHog+N7M8hyUobTrERAqTFAJ9hZRbwl/FO1AUq/0mFOIPRX3L/zQCghTwi mjRzwDXfFoYCCLbY6ITq/Ro= =5afw -END PGP SIGNATURE-
Re: wget-1.11 assertion failed in ru_RU.UTF-8 locale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Shigorin wrote: > Hello Micah, > my friend has found[1] that wget-1.11 introduced a regression: > running it in ru_RU.UTF-8 locale results in failed assertion: > > LC_MESSAGES=ru_RU.UTF-8 wget -c > http://pgfoundry.org/frs/download.php/1559/pgcluster-1.7.0rc8.tar.gz > > complains on (roughly translated since doesn't manifest > with LC_MESSAGES=C): > > progress.c:972: create_image: assertion `p - bp->buffer <= bp->width' failed. Thanks for reporting this. There are various problems with the current progress-drawing code, including that it doesn't count characters properly (counts bytes); and shouldn't need to use a buffer in the first place. I was aware of at least one bug in this section of the code that resulted in a drawing glitch, but didn't realize there was a potential to crash (more than usual, anyway). I'll take a look at what's going on. > Removing /usr/share/locale/ru/LC_MESSAGES/wget.mo does help; > `make update-po' after `configure' and before `make' doesn't. Right; the problem isn't with the .po/.mo files (those shouldn't be capable of crashing programs). > PS: sorry for not subscribing to the list, wget used to be > relatively trouble-free an upstream and I'm subscribed to > a few dozen too much already. Hope you understand :) No need to apologize. :) This list has a policy of encouraging non-subscribers to post. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHn8ae7M8hyUobTrERArBMAJ97F++K4zDDYCq7hqxeRf52C+8P7QCcDeMs rV+FWdBBwKafjEJuV2EOF2c= =j/6f -END PGP SIGNATURE-
Re: wget 1.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Roderburg wrote: > Hmm, these are "really strange cases" with some "really strange hosts" only. > Involved are content-disposition (again ;-) and redirection. Often wget > somehow > "loses" the Content-Length information and keeps on downloading "ad > infinitum". > I did not yet try to research it in detail, but help me with > no-content-disposition and -O to set the file-name, which always works. Good thing that content-disposition is an "experimental" feature, I suppose. That'll be one of my priorities for the next release. Please do send some failure cases when you have the chance. Always good to know what's going wrong. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHlRU97M8hyUobTrERAqNkAJ9HCEtJ1vTeIisA7YeijzbGYpoMMQCeOHRi zrHrQ7pdB68OhOVRF+iRR40= =B13I -END PGP SIGNATURE-
Re: wget 1.11
Zitat von Micah Cowan <[EMAIL PROTECTED]>: > > Just curious: what is now holding back a release of the 1.11 version? > > *sigh*, just waiting on the disclaimer from my employer. I actually > really expect to get that finished up this week, though. I'm told that > the company lawyer has already approved it, but they need to get that > approval back in writing, so it should be _really_ soon. Ah, that is now a type of reason I had not thought of ;-) > > > And I have already again a number of my "strange cases" which I did not > want to > > report during the "last minutes" before the anticipated release ;-) > > Oh noes!... well, better sock 'em to me. Better to know about them than > to remain ignorant, at any rate. The worst that can happen is I decide > to punt 'em until a 1.11 patch release, or later: and if they're really > _really_ awful (which seems relatively unlikely at this point, but...), > then I'll want to fix them ASAP before the release. Hmm, these are "really strange cases" with some "really strange hosts" only. Involved are content-disposition (again ;-) and redirection. Often wget somehow "loses" the Content-Length information and keeps on downloading "ad infinitum". I did not yet try to research it in detail, but help me with no-content-disposition and -O to set the file-name, which always works. Best Regards, Jochen Roderburg ZAIK/RRZK University of Cologne Robert-Koch-Str. 10Tel.: +49-221/478-7024 D-50931 Koeln E-Mail: [EMAIL PROTECTED] Germany
Re: wget 1.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christopher G. Lewis wrote: > Micah - > > I've been quite busy with work stuff (end of the year is killer for me) so > can you give me a quick update on what needs to be done for wget for 1.11 Codewise, zilch (unless Jochen brings something crucial up of which I'm aware). It's literally just waiting on paperwork (my employer-signed waiver). > Building this shows the following version: > > C:\CVSProjects\Hg\Wget\1.11>src\wget.exe --help > GNU Wget 1.10+devel, a non-interactive network retriever. > Usage: wget [OPTION]... [URL]... > > So this is still flagged as 1.10+dev. Yes. I have a patch to fix the version, which will be applied just prior to the release. > Note that I was never able to get *any* of the automated stuff into the MAKE > file for the windows version. NMake just doesn't have the capabilities that > you are putting into the unix versions, and (reiterating) I am quite > hesitant to put something into the build process that requires anything but > the basic compiler. I really believe that having the build process > dependant on the source control system is a *bad* idea. As I've already pointed out previously, it does not rely on the build system. It takes advantage of its presence, when available. I believe I already gave detailed instructions, including a patch, on how to accomplish this with Nmake, etc. In any case, it's a moot point for 1.11, which doesn't have any of that stuff in it. > Also, as it stands - I haven't updated my automated build to Hg - so it's > still building off of SVN. I'm tempted to just post the 1.11 branch as it > stands as a "beta" release, but again, haven't had much time. That's fine; SVN will be kept in-sync, code-wise, for 1.11, after which release it will no longer be updated. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHk++e7M8hyUobTrERAs9AAJ4qBY/BW1Qf81D83UrN/l0S85u2lACfYdtJ Dq2NWsHfrpQGJZfNPhM3f9g= =C1r+ -END PGP SIGNATURE-
RE: wget 1.11
Micah - I've been quite busy with work stuff (end of the year is killer for me) so can you give me a quick update on what needs to be done for wget for 1.11 Currently, I've got a batch file for getting the current wget: C:\Projects\Hg\Wget>type HgGet_1.11.bat @ECHO OFF Pushd 1.11 hg pull http://hg.addictivecode.org/wget/1.11 hg update PopD Which, I believe, gets the current wget from the 1.11 branch and applies (updates) the changes. As stated below, nothing has changed recently. Building this shows the following version: C:\CVSProjects\Hg\Wget\1.11>src\wget.exe --help GNU Wget 1.10+devel, a non-interactive network retriever. Usage: wget [OPTION]... [URL]... So this is still flagged as 1.10+dev. Note that I was never able to get *any* of the automated stuff into the MAKE file for the windows version. NMake just doesn't have the capabilities that you are putting into the unix versions, and (reiterating) I am quite hesitant to put something into the build process that requires anything but the basic compiler. I really believe that having the build process dependant on the source control system is a *bad* idea. Also, as it stands - I haven't updated my automated build to Hg - so it's still building off of SVN. I'm tempted to just post the 1.11 branch as it stands as a "beta" release, but again, haven't had much time. Any insight would be indeed helpful at this point. Chris Christopher G. Lewis http://www.ChristopherLewis.com > -Original Message- > From: Micah Cowan [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 20, 2008 4:19 PM > To: Jochen Roderburg > Cc: wget@sunsite.dk > Subject: Re: wget 1.11 > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jochen Roderburg wrote: > > Hi Michael, > > > > Just curious: what is now holding back a release of the > 1.11 version? > > *sigh*, just waiting on the disclaimer from my employer. I actually > really expect to get that finished up this week, though. I'm told that > the company lawyer has already approved it, but they need to get that > approval back in writing, so it should be _really_ soon. > > > I have not seen any changes in the source repository for a month. > > Well, that's a separate issue. :) > > There'll be an influx of check-ins releated to new > translations shortly > before 1.11 goes out. However, holdups in 1.11 are no excuse > for me not > to be working on 1.12. I've been a bit short on time lately, > but hope to > get back into the swing of things. > > Even so, I think some of the changes I was last working on > may not have > been complete enough to check into public repos. I'm currently working > on some of the things to do with "make check", which is > currently broken > in the mainline repo. I'm not certain whether I intend to fix it as it > is. The unit tests will definitely stay, and perhaps be augmented; > however, the functionality, ".px" tests, I'm less sure about. > They would > be a terrific asset if they were all returning pass/fail > values instead > of relying on human analysis; probably I need to manually > prowl through > them and modify them so they're suitable for automation, and discard > those that cannot be. I do not intend to make "testing" > involve a lot of > manual labor: that labor should go into "bug-smashing". :) > > After that, I'll probably be doing some non-functional > changes, such as > refactoring. I wasn't planning on doing public checkins of that until > it's complete, but perhaps it would be wise at this juncture, given my > rate of progress, to start a new repo to hold that work, so it's at > least visible. > > I have been spending some time in thought and rough design > for Wget 2.0 > stuff, but nothing worth sharing just yet. > > > And I have already again a number of my "strange cases" > which I did not want to > > report during the "last minutes" before the anticipated release ;-) > > Oh noes!... well, better sock 'em to me. Better to know about > them than > to remain ignorant, at any rate. The worst that can happen is I decide > to punt 'em until a 1.11 patch release, or later: and if > they're really > _really_ awful (which seems relatively unlikely at this > point, but...), > then I'll want to fix them ASAP before the release. > > - -- > Micah J. Cowan > Programmer, musician, typesetting enthusiast, gamer... > http://micah.cowan.name/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHk8ju7M8hyUobTrERAnlXAJ4uAiuPA540xYARCOYvBL6EHPU5AACePUOz > iSWr+wXyx09YfKeaeFRnnWA= > =btLR > -END PGP SIGNATURE- > smime.p7s Description: S/MIME cryptographic signature
Re: wget 1.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jochen Roderburg wrote: > Hi Michael, > > Just curious: what is now holding back a release of the 1.11 version? *sigh*, just waiting on the disclaimer from my employer. I actually really expect to get that finished up this week, though. I'm told that the company lawyer has already approved it, but they need to get that approval back in writing, so it should be _really_ soon. > I have not seen any changes in the source repository for a month. Well, that's a separate issue. :) There'll be an influx of check-ins releated to new translations shortly before 1.11 goes out. However, holdups in 1.11 are no excuse for me not to be working on 1.12. I've been a bit short on time lately, but hope to get back into the swing of things. Even so, I think some of the changes I was last working on may not have been complete enough to check into public repos. I'm currently working on some of the things to do with "make check", which is currently broken in the mainline repo. I'm not certain whether I intend to fix it as it is. The unit tests will definitely stay, and perhaps be augmented; however, the functionality, ".px" tests, I'm less sure about. They would be a terrific asset if they were all returning pass/fail values instead of relying on human analysis; probably I need to manually prowl through them and modify them so they're suitable for automation, and discard those that cannot be. I do not intend to make "testing" involve a lot of manual labor: that labor should go into "bug-smashing". :) After that, I'll probably be doing some non-functional changes, such as refactoring. I wasn't planning on doing public checkins of that until it's complete, but perhaps it would be wise at this juncture, given my rate of progress, to start a new repo to hold that work, so it's at least visible. I have been spending some time in thought and rough design for Wget 2.0 stuff, but nothing worth sharing just yet. > And I have already again a number of my "strange cases" which I did not want > to > report during the "last minutes" before the anticipated release ;-) Oh noes!... well, better sock 'em to me. Better to know about them than to remain ignorant, at any rate. The worst that can happen is I decide to punt 'em until a 1.11 patch release, or later: and if they're really _really_ awful (which seems relatively unlikely at this point, but...), then I'll want to fix them ASAP before the release. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHk8ju7M8hyUobTrERAnlXAJ4uAiuPA540xYARCOYvBL6EHPU5AACePUOz iSWr+wXyx09YfKeaeFRnnWA= =btLR -END PGP SIGNATURE-
Re: wget 1.11 beta 1 released
Oliver Schulze L. ha scritto: Does this version have the conection cache code? no, not yet. i have some preliminary code for connection caching, but i am not going to finish it and merge it into the trunk before wget 1.11 is released. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 beta 1 released
Does this version have the conection cache code? Can't find info about it in the changelog: http://svn.dotsrc.org/repo/wget/trunk/src/ChangeLog Thanks Oliver Mauro Tortonesi wrote: hi to everybody, i've just released wget 1.11 beta 1: ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-beta-1.tar.gz you're very welcome to try it and report every bug you might encounter. -- Oliver Schulze L. Get my e-mail after a captcha test in: http://tinymailto.com/oliver
Re: wget 1.11 beta1 another time-stamping problem
Zitat von Jochen Roderburg <[EMAIL PROTECTED]>: > In the time-stamping mode wget always issued first a HEAD request when there > was > a local file, and later a GET request when after inspecting the HEAD outpout > it > found out that it should do so. > > The wget 1.11 now *always* does the HEAD request, so this problem may be a > little related to the other just-repaired problem. Now I even stumbled over a case where this behaviour leads to an error, namely when the server doesn't like the HEAD request and responds with an error. Therefore my additional question: Is this HEAD request intended or is it an error? Has it perhaps to do with the new "Content-Disposition" stuff? I encountered the new problem when downloading a new Eudora Beta. This is delivered via a cgi which makes a redirection to the real file link. A HEAD request for the original link is answered with "500 Server Error". wget.111b1 -d http://www.eudora.com/cgi-bin/export.cgi?productid=EUDORA_win_7106 DEBUG output created by Wget 1.11-beta-1 on linux-gnu. --10:53:19-- http://www.eudora.com/cgi-bin/export.cgi?productid=EUDORA_win_7106 Resolving www.eudora.com... 199.106.114.30 Caching www.eudora.com => 199.106.114.30 Connecting to www.eudora.com|199.106.114.30|:80... connected. Created socket 3. Releasing 0x08086920 (new refcount 1). ---request begin--- HEAD /cgi-bin/export.cgi?productid=EUDORA_win_7106 HTTP/1.0 User-Agent: Wget/1.11-beta-1 Accept: */* Host: www.eudora.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 500 Server Error Server: Netscape-Enterprise/6.0 Date: Wed, 30 Aug 2006 08:53:20 GMT Content-length: 305 Content-type: text/html Connection: keep-alive ---response end--- 500 Server Error Registered socket 3 for persistent reuse. 10:53:21 ERROR 500: Server Error. wget.1102 -d http://www.eudora.com/cgi-bin/export.cgi?productid=EUDORA_win_7106 DEBUG output created by Wget 1.10.2 on linux-gnu. --10:51:22-- http://www.eudora.com/cgi-bin/export.cgi?productid=EUDORA_win_7106 => `export.cgi?productid=EUDORA_win_7106' Resolving www.eudora.com... 199.106.114.30 Caching www.eudora.com => 199.106.114.30 Connecting to www.eudora.com|199.106.114.30|:80... connected. Created socket 3. Releasing 0x08084e60 (new refcount 1). ---request begin--- GET /cgi-bin/export.cgi?productid=EUDORA_win_7106 HTTP/1.0 User-Agent: Wget/1.10.2 Accept: */* Host: www.eudora.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 302 Moved Temporarily Server: Netscape-Enterprise/6.0 Date: Wed, 30 Aug 2006 08:51:21 GMT Location: http://www.eudora.com/download/eudora/windows/7.1/beta/Eudora_7.1.0.6_beta.exe Content-length: 0 Connection: keep-alive ---response end--- 302 Moved Temporarily Registered socket 3 for persistent reuse. Location: http://www.eudora.com/download/eudora/windows/7.1/beta/Eudora_7.1.0.6_beta.exe [ following] Skipping 0 bytes of body: [] done. --10:51:22-- http://www.eudora.com/download/eudora/windows/7.1/beta/Eudora_7.1.0.6_beta.e xe => `Eudora_7.1.0.6_beta.exe' Reusing existing connection to www.eudora.com:80. Reusing fd 3. ---request begin--- GET /download/eudora/windows/7.1/beta/Eudora_7.1.0.6_beta.exe HTTP/1.0 User-Agent: Wget/1.10.2 Accept: */* Host: www.eudora.com Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Server: Netscape-Enterprise/6.0 Date: Wed, 30 Aug 2006 08:51:21 GMT Content-type: application/octet-stream Last-modified: Mon, 28 Aug 2006 21:29:37 GMT Content-length: 17403352 Accept-ranges: bytes Connection: keep-alive ---response end--- 200 OK Length: 17,403,352 (17M) [application/octet-stream] 100%[==>] 17,403,352 322.84K/s ETA 00:00 10:52:29 (256.51 KB/s) - `Eudora_7.1.0.6_beta.exe' saved [17403352/17403352] Regards, J.Roderburg
Re: wget 1.11 beta 1 released
Christopher G. Lewis ha scritto: I've updated the Windows binaries to include Beta 1, and included a binary with Beta 1 + today's patch 2186 & 2187 for spider recursive mode. Available here: http://www.ChristopherLewis.com\wget thank you very much, chris. you're doing an awesome work. And sorry to those who have been having some problems downloading the ZIPs from my site. I had some weird IIS gzip compression issues. we should plan to move the win32 binaries page to wget.sunsite.dk immediately after the 1.11 release. what do you think? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Jochen Roderburg wrote: I have now tested the new wget 1.11 beta1 on my Linux system and the above issue is solved now. The "Remote file is newer" message now only appears when the local file exists and most of the other logic with time-stamping and file-naming works like expected. excellent. I meanwhile found, however, another new problem with time-stamping, which mainly occurs in connection with a proxy-cache, I will report that in a new thread. Same for a small problem with the SSL configuration. thank you very much for the useful bug reports you keep sending us ;-) -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 beta 1 released
Noèl Köthe ha scritto: Am Dienstag, den 22.08.2006, 17:00 +0200 schrieb Mauro Tortonesi: Hello, Mauro, i've just released wget 1.11 beta 1: Thanks.:) you're very welcome to try it and report every bug you might encounter. ... /usr/bin/make install DESTDIR=/home/nk/debian/wget/wget-experimental/wget-1.10.2+1.11.beta1/debian/wget make[1]: Entering directory `/home/nk/debian/wget/wget-experimental/wget-1.10.2+1.11.beta1' cd src && /usr/bin/make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/etc/wgetrc\" -DLOCALEDIR=\"/usr/share/locale\"' CFLAGS='-D_FILE_OFFSET_BITS=64 -g -Wall' LDFLAGS='' LIBS='-ldl -lrt -lssl -lcrypto ' DESTDIR='' prefix='/usr' exec_prefix='/usr' bindir='/usr/bin' infodir='/usr/share/info' mandir='/usr/share/man' manext='1' install.bin make[2]: Entering directory `/home/nk/debian/wget/wget-experimental/wget-1.10.2+1.11.beta1/src' ../mkinstalldirs /usr/bin /usr/bin/install -c wget /usr/bin/wget ... I set DESTDIR in line 1 to install it somewhere but in line 3 DESTDIR='' The problem should be fixed by this: --- Makefile.in.orig2006-08-25 19:53:41.0 +0200 +++ Makefile.in 2006-08-25 19:53:55.0 +0200 @@ -77,7 +77,7 @@ # flags passed to recursive makes in subdirectories MAKEDEFS = CC='$(CC)' CPPFLAGS='$(CPPFLAGS)' DEFS='$(DEFS)' \ CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' LIBS='$(LIBS)' \ -DESTDIR='$(DESTDIR=)' prefix='$(prefix)' exec_prefix='$(exec_prefix)' \ +DESTDIR='$(DESTDIR)' prefix='$(prefix)' exec_prefix='$(exec_prefix)' \ bindir='$(bindir)' infodir='$(infodir)' mandir='$(mandir)' \ manext='$(manext)' Fixed, thanks. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Zitat von Mauro Tortonesi <[EMAIL PROTECTED]>: > > > > The timestamping issues I reported in above mentioned message are now also > > repaired by the patch you mailed last week here. > > Only the small *cosmetic* issue remains that it *always* says: > >Remote file is newer, retrieving. > > even if there is no local file yet. > > i have been working on the problem you reported for the last couple of days. > i've just committed a patch that should fix it for good. could you please try > the new HTTP code and tell me if it works properly? > Hi Mauro, I have now tested the new wget 1.11 beta1 on my Linux system and the above issue is solved now. The "Remote file is newer" message now only appears when the local file exists and most of the other logic with time-stamping and file-naming works like expected. I meanwhile found, however, another new problem with time-stamping, which mainly occurs in connection with a proxy-cache, I will report that in a new thread. Same for a small problem with the SSL configuration. Thanks for the continuing work on my most-used utility ;-) J.Roderburg
Re: wget 1.11 beta 1 released
Am Dienstag, den 22.08.2006, 17:00 +0200 schrieb Mauro Tortonesi: Hello, Mauro, > i've just released wget 1.11 beta 1: Thanks.:) > you're very welcome to try it and report every bug you might encounter. ... /usr/bin/make install DESTDIR=/home/nk/debian/wget/wget-experimental/wget-1.10.2+1.11.beta1/debian/wget make[1]: Entering directory `/home/nk/debian/wget/wget-experimental/wget-1.10.2+1.11.beta1' cd src && /usr/bin/make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/etc/wgetrc\" -DLOCALEDIR=\"/usr/share/locale\"' CFLAGS='-D_FILE_OFFSET_BITS=64 -g -Wall' LDFLAGS='' LIBS='-ldl -lrt -lssl -lcrypto ' DESTDIR='' prefix='/usr' exec_prefix='/usr' bindir='/usr/bin' infodir='/usr/share/info' mandir='/usr/share/man' manext='1' install.bin make[2]: Entering directory `/home/nk/debian/wget/wget-experimental/wget-1.10.2+1.11.beta1/src' ../mkinstalldirs /usr/bin /usr/bin/install -c wget /usr/bin/wget ... I set DESTDIR in line 1 to install it somewhere but in line 3 DESTDIR='' The problem should be fixed by this: --- Makefile.in.orig2006-08-25 19:53:41.0 +0200 +++ Makefile.in 2006-08-25 19:53:55.0 +0200 @@ -77,7 +77,7 @@ # flags passed to recursive makes in subdirectories MAKEDEFS = CC='$(CC)' CPPFLAGS='$(CPPFLAGS)' DEFS='$(DEFS)' \ CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)' LIBS='$(LIBS)' \ -DESTDIR='$(DESTDIR=)' prefix='$(prefix)' exec_prefix='$(exec_prefix)' \ +DESTDIR='$(DESTDIR)' prefix='$(prefix)' exec_prefix='$(exec_prefix)' \ bindir='$(bindir)' infodir='$(infodir)' mandir='$(mandir)' \ manext='$(manext)' -- Noèl Köthe Debian GNU/Linux, www.debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
RE: wget 1.11 beta 1 released
I've updated the Windows binaries to include Beta 1, and included a binary with Beta 1 + today's patch 2186 & 2187 for spider recursive mode. Available here: http://www.ChristopherLewis.com\wget And sorry to those who have been having some problems downloading the ZIPs from my site. I had some weird IIS gzip compression issues. Chris Christopher G. Lewis http://www.ChristopherLewis.com > -Original Message- > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 22, 2006 10:01 AM > To: wget@sunsite.dk > Subject: wget 1.11 beta 1 released > > > hi to everybody, > > i've just released wget 1.11 beta 1: > > ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-beta-1.tar.gz > > you're very welcome to try it and report every bug you might > encounter. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi http://www.tortonesi.com > > University of Ferrara - Dept. of Eng.http://www.ing.unife.it > GNU Wget - HTTP/FTP file retrieval tool > http://www.gnu.org/software/wget > Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it >
RE: wget 1.11 beta 1 released
Does this happen to resolve the issue I asked about a few days ago (no response yet) where DNS doesn't resolve in the presence of an authenticated proxy? > -Original Message- > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 22, 2006 8:01 AM > To: wget@sunsite.dk > Subject: wget 1.11 beta 1 released > > > hi to everybody, > > i've just released wget 1.11 beta 1: > > ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-beta-1.tar.gz > > you're very welcome to try it and report every bug you might > encounter.
Re: wget 1.11 beta 1 released
> you're very welcome to try it and report every bug you might encounter. Same failure (as wget 1.11 alpha 1) to fetch any files with "wget -r ftp://xxx"; from a VMS FTP server. See: http://www.mail-archive.com/wget@sunsite.dk/msg09074.html Steven M. Schweda [EMAIL PROTECTED] 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Jochen Roderburg ha scritto: Zitat von Jochen Roderburg <[EMAIL PROTECTED]>: Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>: Mauro, you will need to look at this one. Part of the problem is that Wget decides to save to index.html.1 although -c is in use. That is solved with the patch attached below. But the other part is that hstat.local_file is a NULL pointer when stat(hstat.local_file, &st) is used to determine whether the file already exists in the -c case. That seems to be a result of your changes to the code -- previously, hstat.local_file would get initialied in http_loop. This looks as if if could also be the cause for the problems which I reported some weeks ago for the timestamping mode (http://www.mail-archive.com/wget@sunsite.dk/msg09083.html) Hello Mauro, The timestamping issues I reported in above mentioned message are now also repaired by the patch you mailed last week here. Only the small *cosmetic* issue remains that it *always* says: Remote file is newer, retrieving. even if there is no local file yet. hi jochen, i have been working on the problem you reported for the last couple of days. i've just committed a patch that should fix it for good. could you please try the new HTTP code and tell me if it works properly? thank you very much for your help. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Zitat von Jochen Roderburg <[EMAIL PROTECTED]>: > Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>: > > > Mauro, you will need to look at this one. Part of the problem is that > > Wget decides to save to index.html.1 although -c is in use. That is > > solved with the patch attached below. But the other part is that > > hstat.local_file is a NULL pointer when > > stat(hstat.local_file, &st) is used to determine whether the file > > already exists in the -c case. That seems to be a result of your > > changes to the code -- previously, hstat.local_file would get > > initialied in http_loop. > > This looks as if if could also be the cause for the problems which I reported > some weeks ago for the timestamping mode > (http://www.mail-archive.com/wget@sunsite.dk/msg09083.html) > Hello Mauro, The timestamping issues I reported in above mentioned message are now also repaired by the patch you mailed last week here. Only the small *cosmetic* issue remains that it *always* says: Remote file is newer, retrieving. even if there is no local file yet. J.Roderburg
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Hrvoje Niksic ha scritto: Mauro Tortonesi <[EMAIL PROTECTED]> writes: you're right, of course. the patch included in attachment should fix the problem. since the new HTTP code supports Content-Disposition and delays the decision of the destination filename until it receives the response header, the best solution i could find to make -c work is to send a HEAD request to determine the actual destination filename before resuming download if -c is given. please, let me know what you think. I don't like the additional HEAD request, but I can't think of a better solution. same for me. in order to avoid the overhead of the extra HEAD request, i had considered disabling Content-Disposition and using url_file_name to determine the destination filename in case -c is given. but i really didn't like that solution. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Mauro Tortonesi <[EMAIL PROTECTED]> writes: > you're right, of course. the patch included in attachment should fix > the problem. since the new HTTP code supports Content-Disposition > and delays the decision of the destination filename until it > receives the response header, the best solution i could find to make > -c work is to send a HEAD request to determine the actual > destination filename before resuming download if -c is given. > > please, let me know what you think. I don't like the additional HEAD request, but I can't think of a better solution.
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Hrvoje Niksic ha scritto:
Noèl Köthe <[EMAIL PROTECTED]> writes:
a wget -c problem report with the 1.11 alpha 1 version
(http://bugs.debian.org/378691):
I can reproduce the problem. If I have already 1 MB downloaded wget -c
doesn't continue. Instead it starts to download again:
Mauro, you will need to look at this one. Part of the problem is that
Wget decides to save to index.html.1 although -c is in use. That is
solved with the patch attached below. But the other part is that
hstat.local_file is a NULL pointer when
stat(hstat.local_file, &st) is used to determine whether the file
already exists in the -c case. That seems to be a result of your
changes to the code -- previously, hstat.local_file would get
initialied in http_loop.
The partial patch follows:
Index: src/http.c
===
--- src/http.c (revision 2178)
+++ src/http.c (working copy)
@@ -1762,7 +1762,7 @@
return RETROK;
}
- else
+ else if (!ALLOW_CLOBBER)
{
char *unique = unique_name (hs->local_file, true);
if (unique != hs->local_file)
you're right, of course. the patch included in attachment should fix the
problem. since the new HTTP code supports Content-Disposition and delays the
decision of the destination filename until it receives the response header, the
best solution i could find to make -c work is to send a HEAD request to
determine the actual destination filename before resuming download if -c is given.
please, let me know what you think.
--
Aequam memento rebus in arduis servare mentem...
Mauro Tortonesi http://www.tortonesi.com
University of Ferrara - Dept. of Eng.http://www.ing.unife.it
GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget
Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net
Ferrara Linux User Group http://www.ferrara.linux.it
Index: http.c
===
--- http.c (revisione 2178)
+++ http.c (copia locale)
@@ -1762,7 +1762,7 @@
return RETROK;
}
- else
+ else if (!ALLOW_CLOBBER)
{
char *unique = unique_name (hs->local_file, true);
if (unique != hs->local_file)
@@ -2231,6 +2231,7 @@
{
int count;
bool got_head = false; /* used for time-stamping */
+ bool got_name = false;
char *tms;
const char *tmrate;
uerr_t err, ret = TRYLIMEXC;
@@ -2264,7 +2265,10 @@
hstat.referer = referer;
if (opt.output_document)
+{
hstat.local_file = xstrdup (opt.output_document);
+ got_name = true;
+}
/* Reset the counter. */
count = 0;
@@ -2309,13 +2313,16 @@
/* Default document type is empty. However, if spider mode is
on or time-stamping is employed, HEAD_ONLY commands is
encoded within *dt. */
- if ((opt.spider && !opt.recursive) || (opt.timestamping && !got_head))
+ if ((opt.spider && !opt.recursive)
+ || (opt.timestamping && !got_head)
+ || (opt.always_rest && !got_name))
*dt |= HEAD_ONLY;
else
*dt &= ~HEAD_ONLY;
/* Decide whether or not to restart. */
if (opt.always_rest
+ && got_name
&& stat (hstat.local_file, &st) == 0
&& S_ISREG (st.st_mode))
/* When -c is used, continue from on-disk size. (Can't use
@@ -2484,6 +2491,12 @@
continue;
}
+ if (opt.always_rest && !got_name)
+{
+ got_name = true;
+ continue;
+}
+
if ((tmr != (time_t) (-1))
&& (!opt.spider || opt.recursive)
&& ((hstat.len == hstat.contlen) ||
Index: ChangeLog
===
--- ChangeLog (revisione 2178)
+++ ChangeLog (copia locale)
@@ -1,3 +1,9 @@
+2006-08-16 Mauro Tortonesi <[EMAIL PROTECTED]>
+
+ * http.c: Fixed bug which broke --continue feature. Now if -c is
+ given, http_loop sends a HEAD request to find out the destination
+ filename before resuming download.
+
2006-08-08 Hrvoje Niksic <[EMAIL PROTECTED]>
* utils.c (datetime_str): Avoid code repetition with time_str.
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Hrvoje Niksic wrote: Noèl Köthe <[EMAIL PROTECTED]> writes: a wget -c problem report with the 1.11 alpha 1 version (http://bugs.debian.org/378691): I can reproduce the problem. If I have already 1 MB downloaded wget -c doesn't continue. Instead it starts to download again: Mauro, you will need to look at this one. i surely will. unfortunately, at the moment i am attending the winsys 2006 research conference: http://www.winsys.org i'll take a look at the problem as soon as i get back to italy. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>: > Mauro, you will need to look at this one. Part of the problem is that > Wget decides to save to index.html.1 although -c is in use. That is > solved with the patch attached below. But the other part is that > hstat.local_file is a NULL pointer when > stat(hstat.local_file, &st) is used to determine whether the file > already exists in the -c case. That seems to be a result of your > changes to the code -- previously, hstat.local_file would get > initialied in http_loop. This looks as if if could also be the cause for the problems which I reported some weeks ago for the timestamping mode (http://www.mail-archive.com/wget@sunsite.dk/msg09083.html) J.Roderburg
Re: wget 1.11 alpha1 [Fwd: Bug#378691: wget --continue doesn't workwith HTTP]
Noèl Köthe <[EMAIL PROTECTED]> writes:
> a wget -c problem report with the 1.11 alpha 1 version
> (http://bugs.debian.org/378691):
>
> I can reproduce the problem. If I have already 1 MB downloaded wget -c
> doesn't continue. Instead it starts to download again:
Mauro, you will need to look at this one. Part of the problem is that
Wget decides to save to index.html.1 although -c is in use. That is
solved with the patch attached below. But the other part is that
hstat.local_file is a NULL pointer when
stat(hstat.local_file, &st) is used to determine whether the file
already exists in the -c case. That seems to be a result of your
changes to the code -- previously, hstat.local_file would get
initialied in http_loop.
The partial patch follows:
Index: src/http.c
===
--- src/http.c (revision 2178)
+++ src/http.c (working copy)
@@ -1762,7 +1762,7 @@
return RETROK;
}
- else
+ else if (!ALLOW_CLOBBER)
{
char *unique = unique_name (hs->local_file, true);
if (unique != hs->local_file)
Re: wget 1.11 alpha1 - content disposition filename
Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>: > Jochen Roderburg <[EMAIL PROTECTED]> writes: > > > E.g, a file which was supposed to have the name B&W.txt came with the > header: > > Content-Disposition: attachment; filename=B&W.txt; > > All programs I tried (the new wget and several browsers and my own script > ;-) > > seemed to stop parsing at the first semicolon and produced the filename > B&. > > Unfortunately, if it doesn't work in web browsers, how can it be > expected to work in Wget? The server-side software should be fixed. > I mainly wanted to hear from some "HTTP/HTML-Experts" that I was correct with my assumption that the problem here is at the server side ;-) Thank you, Mauro and Hrvoje, for confirming that. Regards, J.Roderburg
Re: wget 1.11 alpha1 - content disposition filename
Jochen Roderburg <[EMAIL PROTECTED]> writes: > E.g, a file which was supposed to have the name B&W.txt came with the header: > Content-Disposition: attachment; filename=B&W.txt; > All programs I tried (the new wget and several browsers and my own script ;-) > seemed to stop parsing at the first semicolon and produced the filename B&. Unfortunately, if it doesn't work in web browsers, how can it be expected to work in Wget? The server-side software should be fixed.
Re: wget 1.11 alpha1 - content disposition filename
Jochen Roderburg ha scritto: Hi, I was happy to see that a long missed future was now implemented in this alpha, namely the interpretaion of the filename in the content dispostion header. Just recently I had hacked a little script together to achieve this, when I wanted to download a greater number of files where this was used ;-) I had a few cases, however, which did not come out as expected, but I think the error is this time in the sending web application and not in wget. E.g, a file which was supposed to have the name B&W.txt came with the header: Content-Disposition: attachment; filename=B&W.txt; the error is definitely in the web application. the correct header would be: Content-Disposition: attachment; filename="B&W.txt"; All programs I tried (the new wget and several browsers and my own script ;-) seemed to stop parsing at the first semicolon and produced the filename B&. Any thoughts ?? i think that the filename parsing heuristics currently implemented in wget are fine. you really can't do much better in this case. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: Windows compler need (was RE: wget 1.11 alpha 1 released)
Christopher G. Lewis ha scritto: OK, the Win32 compile is working, I've got both the SVN Trunk and the 1.11 alpha branch from ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz . We'll obviously work through the warnings that are coming up, and re-address the CL parameters to fit with the VS 2005 C Compiler. excellent. I think we should make this the default supported compiler for the 1.11 release if we can confirm that we compile with VC++ Express (which is free from MS). i agree. MSVC 14 (AKA Visual Studio 2005's C Compiler) should be the default supported compiler for the future Wget releases. fortunately, i have been able to setup a build environment w/ MSVC 14 on my laptop so from now on i'll be able to help w/ Win32-related problems. We should also double check on OpenSSL, since MS has now includes MASM as a free download for VC++ Express users. I'm going to have to spin up a VM to test the VC++ Express compile - I should be able to do this sometime this weekend. does VC++ Express provide also nmake? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha 1 released
Herold Heiko <[EMAIL PROTECTED]> writes: > The --ignore-case (and wgetrc option) don't seem to be documented in > the texi. Fixed now, thanks for the report!
RE: Windows compler need (was RE: wget 1.11 alpha 1 released)
> From: Christopher G. Lewis [mailto:[EMAIL PROTECTED] > The only other issue I have right now is the MakeInfo program > doesn't seem > to be working correctly. > I downloaded the latest version from GNU (TextInfo 4.8), but > So am not able to produce the Help file. Note that I do > remember at one > point in around the 1.6 or 1.8 branch I was able to get this > to work. I Cristopher, I tried with the old makeinfo I had on my system and it worked fine. Maybe we should take a look at the makeinfo Changelog and take a look what the say for old script conversion, in the meantime at least this should enable you to get a working version. makeinfo (GNU texinfo 3.11) 1.68 RTF/HTML additions by [EMAIL PROTECTED] Copyright (C) 1996 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 / +39-041-5917073 ph -- +39-041-5907472 / +39-041-5917472 fax
RE: wget 1.11 alpha 1 released
The --ignore-case (and wgetrc option) don't seem to be documented in the texi. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 / +39-041-5917073 ph -- +39-041-5907472 / +39-041-5917472 fax > -Original Message- > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 13, 2006 5:06 PM > To: wget@sunsite.dk > Subject: wget 1.11 alpha 1 released > > > > hi to everybody, > > i've just released wget 1.11 alpha 1: > > ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz > > you're very welcome to try it and report every bug you might > encounter. > > > with this release, the development cicle for 1.11 officially > enters the > feature freeze state. wget 1.11 final will be released when all the > following tasks are completed: > > 1) win32 fixes (setlocale, fork) > 2) last fixes to -r and --spider > 3) update documentation > 4) return error/warning if multiple HTTP headers w/ same name > are given > 5) return error/warning if conflicting options are given > 6) fix "Saving to:" output in case -O is given > > unfortunately, this means that all the planned major changes (gnunet > support, advanced URL filtering w/ regex, etc...) will have > to wait until > 1.12. however, i think that the many important features and bugfixes > recently commited into the trunk more than justify the new, > upcoming 1.11 > release. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi http://www.tortonesi.com > > University of Ferrara - Dept. of Eng.http://www.ing.unife.it > GNU Wget - HTTP/FTP file retrieval tool > http://www.gnu.org/software/wget > Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it >
RE: Windows compler need (was RE: wget 1.11 alpha 1 released)
OK, the Win32 compile is working, I've got both the SVN Trunk and the 1.11 alpha branch from ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz . We'll obviously work through the warnings that are coming up, and re-address the CL parameters to fit with the VS 2005 C Compiler. I think we should make this the default supported compiler for the 1.11 release if we can confirm that we compile with VC++ Express (which is free from MS). We should also double check on OpenSSL, since MS has now includes MASM as a free download for VC++ Express users. I'm going to have to spin up a VM to test the VC++ Express compile - I should be able to do this sometime this weekend. The only other issue I have right now is the MakeInfo program doesn't seem to be working correctly. I downloaded the latest version from GNU (TextInfo 4.8), but it doesn't seem to support the --hpj parameter: c:\CVSProjects\Wget\wget-1.11-alpha-1\doc>makeinfo --version makeinfo (GNU texinfo) 4.8 Copyright (C) 2004 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. c:\CVSProjects\Wget\wget-1.11-alpha-1\doc>nmake Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. makeinfo.exe --no-validate --no-warn --force --hpj wget.hpj --output wget.rtf wget.texi C:\Program Files\GnuWin32\bin\makeinfo.exe: unrecognized option `--hpj' Try `makeinfo --help' for more information. hcrtf -xn wget.hpj So am not able to produce the Help file. Note that I do remember at one point in around the 1.6 or 1.8 branch I was able to get this to work. I guess that's what I get for Christopher G. Lewis http://www.ChristopherLewis.com > -Original Message- > From: Herold Heiko [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 21, 2006 8:02 AM > To: Christopher G. Lewis > Subject: RE: Windows compler need (was RE: wget 1.11 alpha 1 released) > > Hi, > > only Travis Loyd, however from what I've seen I don't think > he realized we'd > been talking about visual c, so I think you would be the only > candidate. > Thanks for your offer, we will all be grateful! > > Heiko > > -- > -- PREVINET S.p.A. www.previnet.it > -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] > -- +39-041-5907073 / +39-041-5917073 ph > -- +39-041-5907472 / +39-041-5917472 fax > > > -Original Message- > > From: Christopher G. Lewis [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, June 21, 2006 4:10 AM > > To: Herold Heiko > > Subject: RE: Windows compler need (was RE: wget 1.11 alpha > 1 released) > > > > > > Herold - > > > > Has anyone volunteered for the Win32 native build yet? > > > > I'd be willing to at least attempt the build process, > > although the last > > build I did was 1.9 (to attempt to work out some ntlm proxy > > issues I was > > having) > > > > Thanks for all the work. > > > > Chris > > > > > > Christopher G. Lewis > > http://www.ChristopherLewis.com > > > > > > > -Original Message- > > > From: Herold Heiko [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, June 14, 2006 4:37 AM > > > To: wget@sunsite.dk > > > Subject: Windows compler need (was RE: wget 1.11 alpha 1 released) > > > > > > Everybody, > > > if there is somebody willing to step in as compiler of > > > official windows > > > binaries please let yourself heared. > > > As I mentioned before currently I've have neither means nor > > > time to provide > > > even release version binaries, develpoment-HEAD/alpha/beta > > > builds are stuff > > > of dreams; yet there should be downloadable builds for all > > these, too. > > > > > > Beside that I think the current (soon-to-be old) release 1.10 > > > binary should > > > be moved from my home page to the official site, possibly the > > > ftp server > > > (which needs a good cleaning out) or somewhere else. > > > > > > Heiko > > > > > > -- > > > -- PREVINET S.p.A. www.previnet.it > > > -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] > > > -- +39-041-5907073 / +39-041-5917073 ph > > > -- +39-041-5907472 / +39-041-5917472 fax > > > > > > > -Original Message- > > > > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, June 13, 2006 5:06 PM &g
Re: wget 1.11 alpha 1 released
Note that, even if you don't import 1.11 into the current Fedora, you can always take a look at the bugfixes in the 1.10 branch. For example: $ svn diff http://svn.dotsrc.org/repo/wget/tags/WGET_1_10_2 \ http://svn.dotsrc.org/repo/wget/branches/1.10
Re: wget 1.11 alpha 1 released
Mauro Tortonesi schrieb: hi to everybody, i've just released wget 1.11 alpha 1: ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz you're very welcome to try it and report every bug you might encounter. with this release, the development cicle for 1.11 officially enters the feature freeze state. wget 1.11 final will be released when all the following tasks are completed: 1) win32 fixes (setlocale, fork) 2) last fixes to -r and --spider 3) update documentation 4) return error/warning if multiple HTTP headers w/ same name are given 5) return error/warning if conflicting options are given 6) fix "Saving to:" output in case -O is given unfortunately, this means that all the planned major changes (gnunet support, advanced URL filtering w/ regex, etc...) will have to wait until 1.12. however, i think that the many important features and bugfixes recently commited into the trunk more than justify the new, upcoming 1.11 release. Hello, When do you expect to release 1.11 ? I'd like to add the pre-1.11 version to Fedora Core - Development to give it some exposure, but that's only feasible if wget-1.11 is available before Fedora Core 6 enters final devel freeze on 09/19/2006 Karsten -- Karsten Hopp <[EMAIL PROTECTED]> GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111
Re: wget 1.11 alpha 1 released
"Christopher G. Lewis" <[EMAIL PROTECTED]> writes: > c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign > redefinition of type > http.c(540) : warning C4090: 'function' : different 'const' qualifiers > http.c(558) : warning C4090: 'function' : different 'const' qualifiers > http.c(736) : warning C4090: 'function' : different 'const' qualifiers I don't understand this warning. Do you? > c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign > redefinition of type This one (repeated several times) is the result of HAVE_UINTPTR_T being incorrectly defined on your system. That should be fixed in windows/config-compiler.h. > utils.c(1917) : error C2036: 'const void *' : unknown size > utils.c(1917) : error C2036: 'const void *' : unknown size In 1.11-alpha1, the line 1917 contains an assignment from char * to another char *; there is no const void * anywhere. > c:\cvsprojects\wget\trunk\src\openssl.c(152) : warning C4715: > 'key_type_to_ssl_type' : not all control paths return a va > lue The compiler is apparently not aware that abort() aborts. > Looks like the big error is here: > utils.c(1902) > base64_encode (const void *data, int length, char *dest) Which version of Wget are you compiling, exactly? 1.11-alpha1 does not contain such code on line 1902 of utils.c. The latest subversion code does, though, so I guess you are compiling that. The bug is a GCC-ism that crept in unwanted, and this patch (now applied) should fix the it: 2006-06-21 Hrvoje Niksic <[EMAIL PROTECTED]> * utils.c (base64_encode): Cast void pointer to char * before doing arithmetic. Index: src/utils.c === --- src/utils.c (revision 2156) +++ src/utils.c (working copy) @@ -1914,7 +1914,7 @@ }; const unsigned char *s = data; /* Theoretical ANSI violation when length < 3. */ - const unsigned char *end = data + length - 2; + const unsigned char *end = (const unsigned char *) data + length - 2; char *p = dest; /* Transform the 3x8 bits to 4x6 bits, as required by base64. */
RE: wget 1.11 alpha 1 released
Attempting a build with VC 2005: C:\CVSProjects\Wget\trunk>configure.bat --msvc Type NMAKE to start compiling. If it doesn't work, try executing MSDEV\BIN\VCVARS32.BAT first, and then NMAKE. C:\CVSProjects\Wget\trunk>nmake Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. cd src "C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe" Microsoft (R) Program Maintenance Utility Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. cl /nologo /MT /O2 /I. /DWINDOWS /D_CONSOLE /DHAVE_CONFIG_H /DHAVE_SSL /c http.c retr.c utils.c openssl.c http-n tlm.c http.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type http.c(540) : warning C4090: 'function' : different 'const' qualifiers http.c(558) : warning C4090: 'function' : different 'const' qualifiers http.c(736) : warning C4090: 'function' : different 'const' qualifiers retr.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type utils.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type utils.c(1917) : error C2036: 'const void *' : unknown size utils.c(1917) : error C2036: 'const void *' : unknown size openssl.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type http-ntlm.c c:\cvsprojects\wget\trunk\src\sysdep.h(215) : warning C4142: benign redefinition of type Generating Code... c:\cvsprojects\wget\trunk\src\openssl.c(152) : warning C4715: 'key_type_to_ssl_type' : not all control paths return a va lue c:\cvsprojects\wget\trunk\src\http.c(2941) : warning C4715: 'create_authorization_line' : not all control paths return a value NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 8\VC\BIN\nmake.exe"' : return code '0x2' Stop. Looks like the big error is here: utils.c(1902) base64_encode (const void *data, int length, char *dest) A change to char fixes it for Win32 ... base64_encode (const char *data, int length, char *dest) Christopher G. Lewis http://www.ChristopherLewis.com > -Original Message- > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 13, 2006 10:06 AM > To: wget@sunsite.dk > Subject: wget 1.11 alpha 1 released > > > hi to everybody, > > i've just released wget 1.11 alpha 1: > > ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz > > you're very welcome to try it and report every bug you might > encounter. > > > with this release, the development cicle for 1.11 officially > enters the > feature freeze state. wget 1.11 final will be released when all the > following tasks are completed: > > 1) win32 fixes (setlocale, fork) > 2) last fixes to -r and --spider > 3) update documentation > 4) return error/warning if multiple HTTP headers w/ same name > are given > 5) return error/warning if conflicting options are given > 6) fix "Saving to:" output in case -O is given > > unfortunately, this means that all the planned major changes (gnunet > support, advanced URL filtering w/ regex, etc...) will have > to wait until > 1.12. however, i think that the many important features and bugfixes > recently commited into the trunk more than justify the new, > upcoming 1.11 > release. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi http://www.tortonesi.com > > University of Ferrara - Dept. of Eng.http://www.ing.unife.it > GNU Wget - HTTP/FTP file retrieval tool > http://www.gnu.org/software/wget > Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it >
RE: Windows compler need (was RE: wget 1.11 alpha 1 released)
> From: Travis Loyd [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 14, 2006 5:45 PM > Hello gang, I'm considering building the Windows releases for you. > > My initial attempts to build wget resulted in an error when performing > ./configure: Sorry about the delay. Travis, in what environment are you building ? I see configure and bash, I suppose you are trying to build a cygnus binary. While that one needs to be tested, too, I was referring to the native Visual C binary without need for the cygnus runtime. You'll need a current VC environment, build the openssl libraries (the first time and whenever there are important changes like security fixes), add those to the VC environment, configure.bat --msvc, nmake. Can anybody confirm if the current alpha (or at least late subversion exports) does build cleanly ? If not, if there are some problems, if it is the first time you are trying to attempt this, I'd advice to try with the 1.10.1 sources first (since those are known to build cleanly) in order to straight out your setup, if nobody else does step in I'll try to help you whenever possible. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 / +39-041-5917073 ph -- +39-041-5907472 / +39-041-5917472 fax
Re: Windows compler need (was RE: wget 1.11 alpha 1 released)
Figured out my own problem, perhaps someone might alter this in the source tree. The file 'configure.in' has a line as: dnl dnl Create output dnl AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile util/Makefile po/Makefile.in tests/Makefile windows/Makefile]) If the line AC_CONFIG_FILES is altered so that it does not wrap around then everything works in my environment. I think the problem with my tools was a \r\n instead of just \n. But, at the moment can't be sure. Hopefully this was a helpful note. Travis Travis Loyd wrote: > Hello gang, I'm considering building the Windows releases for you. > > My initial attempts to build wget resulted in an error when performing > ./configure: > > gettext not found; disabling NLS > checking for makeinfo... makeinfo > checking for perl5... no > checking for perl... /usr/bin/perl > checking for pod2man... /usr/bin/pod2man > configure: creating ./config.status > config.status: creating Makefile > config.status: creating src/Makefile > config.status: creating doc/Makefile > config.status: creating util/Makefile > .infig.status: error: cannot find input file: util/Makefile > > Then typing ./make didn't do much better: > > bash-3.1$ make > ./config.status > config.status: creating Makefile > config.status: creating src/Makefile > config.status: creating doc/Makefile > config.status: creating util/Makefile > .infig.status: error: cannot find input file: util/Makefile > make: *** [stamp-h] Error 1 > > Is it just me? > > > Travis Loyd > > > > Herold Heiko wrote: >> Everybody, >> if there is somebody willing to step in as compiler of official windows >> binaries please let yourself heared. >> As I mentioned before currently I've have neither means nor time to provide >> even release version binaries, develpoment-HEAD/alpha/beta builds are stuff >> of dreams; yet there should be downloadable builds for all these, too. >> >> Beside that I think the current (soon-to-be old) release 1.10 binary should >> be moved from my home page to the official site, possibly the ftp server >> (which needs a good cleaning out) or somewhere else. >> >> Heiko >> > > signature.asc Description: OpenPGP digital signature
Re: Windows compler need (was RE: wget 1.11 alpha 1 released)
Hello gang, I'm considering building the Windows releases for you. My initial attempts to build wget resulted in an error when performing ./configure: gettext not found; disabling NLS checking for makeinfo... makeinfo checking for perl5... no checking for perl... /usr/bin/perl checking for pod2man... /usr/bin/pod2man configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating doc/Makefile config.status: creating util/Makefile .infig.status: error: cannot find input file: util/Makefile Then typing ./make didn't do much better: bash-3.1$ make ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating doc/Makefile config.status: creating util/Makefile .infig.status: error: cannot find input file: util/Makefile make: *** [stamp-h] Error 1 Is it just me? Travis Loyd Herold Heiko wrote: > Everybody, > if there is somebody willing to step in as compiler of official windows > binaries please let yourself heared. > As I mentioned before currently I've have neither means nor time to provide > even release version binaries, develpoment-HEAD/alpha/beta builds are stuff > of dreams; yet there should be downloadable builds for all these, too. > > Beside that I think the current (soon-to-be old) release 1.10 binary should > be moved from my home page to the official site, possibly the ftp server > (which needs a good cleaning out) or somewhere else. > > Heiko > signature.asc Description: OpenPGP digital signature
Re: Windows compler need (was RE: wget 1.11 alpha 1 released)
Is the process completely scripted & automated by now? I'm assuming it is... including grabbing updated files etc? Travis Loyd Herold Heiko wrote: > Everybody, > if there is somebody willing to step in as compiler of official windows > binaries please let yourself heared. > As I mentioned before currently I've have neither means nor time to provide > even release version binaries, develpoment-HEAD/alpha/beta builds are stuff > of dreams; yet there should be downloadable builds for all these, too. > > Beside that I think the current (soon-to-be old) release 1.10 binary should > be moved from my home page to the official site, possibly the ftp server > (which needs a good cleaning out) or somewhere else. > > Heiko > signature.asc Description: OpenPGP digital signature
Windows compler need (was RE: wget 1.11 alpha 1 released)
Everybody, if there is somebody willing to step in as compiler of official windows binaries please let yourself heared. As I mentioned before currently I've have neither means nor time to provide even release version binaries, develpoment-HEAD/alpha/beta builds are stuff of dreams; yet there should be downloadable builds for all these, too. Beside that I think the current (soon-to-be old) release 1.10 binary should be moved from my home page to the official site, possibly the ftp server (which needs a good cleaning out) or somewhere else. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 / +39-041-5917073 ph -- +39-041-5907472 / +39-041-5917472 fax > -Original Message- > From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 13, 2006 5:06 PM > To: wget@sunsite.dk > Subject: wget 1.11 alpha 1 released > > > > hi to everybody, > > i've just released wget 1.11 alpha 1: > > ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz > > you're very welcome to try it and report every bug you might > encounter. > > > with this release, the development cicle for 1.11 officially > enters the > feature freeze state. wget 1.11 final will be released when all the > following tasks are completed: > > 1) win32 fixes (setlocale, fork) > 2) last fixes to -r and --spider > 3) update documentation > 4) return error/warning if multiple HTTP headers w/ same name > are given > 5) return error/warning if conflicting options are given > 6) fix "Saving to:" output in case -O is given > > unfortunately, this means that all the planned major changes (gnunet > support, advanced URL filtering w/ regex, etc...) will have > to wait until > 1.12. however, i think that the many important features and bugfixes > recently commited into the trunk more than justify the new, > upcoming 1.11 > release. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi http://www.tortonesi.com > > University of Ferrara - Dept. of Eng.http://www.ing.unife.it > GNU Wget - HTTP/FTP file retrieval tool > http://www.gnu.org/software/wget > Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net > Ferrara Linux User Group http://www.ferrara.linux.it >
Re: wget 1.11 alpha 1 released
First, a bit of history... From: Steven M. Schweda 15-DEC-2004 14:19:07.55 > [...] >http://www.antinode.org/dec/sw/wget.html > [...] >From Mauro Tortonesi Sun, 10 Apr 2005 23:21:00 -0500 > [...] > if you want your patches to be merged in our CVS, you should follow > the official patch submission procedure (that is, posting your patches > to the wget-patches AT sunsite DOT dk mailing list. each post should > include a brief comment about what the patch does, and especially why it > does so). this would save a lot of time to me and hrvoje and would > definitely speed up the merging process. > [...] From: Steven M. Schweda Mon, 18 Apr 2005 12:21:44 -0500 (CDT) > [...] > http://antinode.org/ftp/wget/patch1/ > [...] >From Mauro Tortonesi Mon, 19 Sep 2005 17:45:14 +0200 > [...] > the wget code is going through a major refactoring effort. later on, > just before releasing wget 2.0, i promise i will re-evaluate your > patches and merge them if they're not too intrusive. > [...] >From Mauro Tortonesi Tue, 13 Jun 2006 09:38:36 -0700 > [...] > i promise we'll seriously talk about merging your VMS changes into wget > at the beginning of the 1.12 development cycle. > [...] That would be nice, as it would have been nice every other time I've suggested it since Wget 1.9.1 in December 2004. > you'll be very welcome to convince me about the soundness of your code > and the need to merge VMS support into wget [...] Need? None at all, if you have no interest in providing any support for Wget on VMS, and if you have no interest in Wget working well with a VMS FTP server, and if you have no interest in the miscellaneous bug fixes I've made along the way. I simply assumed, as I had done all the necessary work for VMS support (client and server), and fixed a few bugs along the way, that you might find it worth the (pretty small) effort to incorporate my suggested changes. On the topic of the soundness of code, let's consider what happens on a Tru64 system fetching files from a VMS FTP server using the new Wget 1.11-alpha-1, the original Wget 1.10.2, and my Wget 1.10.2b. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - urtx# wg11 -V GNU Wget 1.11-alpha-1 [...] urtx# wg11 -r ftp://alp/wget_test/ --22:15:11-- ftp://alp/wget_test/ => `alp/wget_test/.listing' Resolving alp... 10.0.0.9 Connecting to alp|10.0.0.9|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD [ANONYMOUS.wget_test] ... done. ==> PASV ... done.==> LIST ... done. [ <=>] 32 --.-K/s in 0s 22:15:12 (640 B/s) - `alp/wget_test/.listing' saved [32] Removed `alp/wget_test/.listing'. Wrote HTML-ized index to `alp/wget_test/index.html' [198]. urtx# urtx# cat ./alp/wget_test/index.html Index of /wget_test on alp:21 Index of /wget_test on alp:21 Please observe that no files were downloaded. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - urtx# wg10 -V GNU Wget 1.10.2 [...] urtx# wg10 -r ftp://alp/wget_test/ --22:11:58-- ftp://alp/wget_test/ => `alp/wget_test/.listing' Resolving alp... 10.0.0.9 Connecting to alp|10.0.0.9|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD [ANONYMOUS.wget_test] ... done. ==> PASV ... done.==> LIST ... done. [ <=> ] 284 --.--K/s 22:11:58 (28.40 KB/s) - `alp/wget_test/.listing' saved [284] Removed `alp/wget_test/.listing'. --22:11:58-- ftp://alp/wget_test/EMPTY/ => `alp/wget_test/EMPTY/.listing' ==> CWD [ANONYMOUS.wget_test.EMPTY] ... done. ==> PASV ... done.==> LIST ... done. [ <=> ] 32--.--K/s 22:11:58 (2.91 KB/s) - `alp/wget_test/EMPTY/.listing' saved [32] Removed `alp/wget_test/EMPTY/.listing'. --22:11:58-- ftp://alp/wget_test/EMPTY/ => `alp/wget_test/EMPTY/index.html' ==> CWD not required. ==> PASV ... done.==> RETR ... No such file `'. --22:11:58-- ftp://alp/wget_test/NON-EMPTY/ => `alp/wget_test/NON-EMPTY/.listing' ==> CWD [ANONYMOUS.wget_test.NON-EMPTY] ... done. ==> PASV ... done.==> LIST ... done. [ <=> ] 195 --.--K/s 22:11:58 (16.25 KB/s) - `alp/wget_test/NON-EMPTY/.listing' saved [195] Removed `alp/wget_test/NON-EMPTY/.listing'. --22:11:58-- ftp://alp/wget_test/NON-EMPTY/A.TXT => `alp/wget_test/NON-EMPTY/A.TXT' ==> CWD [ANONYMOUS.wget_test.NON-EMPTY] ... done. ==> PASV ... done.==> RETR A.TXT ... done. Length: 6 (unauthoritative) 100%[>] 6 --.--K/s 22:11:58 (117.19 KB/s) - `alp/wget_test/NON-EMPTY/A.TXT' saved [6] FINISHED --22:11:58-- Downloaded: 6 bytes in 1 files urtx# Please observe the spurious message, "No such file `'.", for the
Re: wget 1.11 alpha 1 released
Steven M. Schweda wrote: From: Mauro Tortonesi ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz I assume that it would be pointless to look for the VMS changes here, but feel free to amaze me. i promise we'll seriously talk about merging your VMS changes into wget at the beginning of the 1.12 development cycle. you'll be very welcome to convince me about the soundness of your code and the need to merge VMS support into wget via your favorite IM tool: http://www.tortonesi.com/contactme.shtml however, for the moment i have to focus on the 1.11 release. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi http://www.tortonesi.com University of Ferrara - Dept. of Eng.http://www.ing.unife.it GNU Wget - HTTP/FTP file retrieval tool http://www.gnu.org/software/wget Deep Space 6 - IPv6 for Linuxhttp://www.deepspace6.net Ferrara Linux User Group http://www.ferrara.linux.it
Re: wget 1.11 alpha 1 released
From: Mauro Tortonesi > ftp://alpha.gnu.org/pub/pub/gnu/wget/wget-1.11-alpha-1.tar.gz I assume that it would be pointless to look for the VMS changes here, but feel free to amaze me. Steven M. Schweda [EMAIL PROTECTED] 382 South Warwick Street(+1) 651-699-9818 Saint Paul MN 55105-2547
