RE: wget 1.10 alpha 2
From: Mauro Tortonesi [mailto:[EMAIL PROTECTED] the patch you've posted is really such an ugly workaround (shame on microsoft Exactly the same opinion here. Please don't misunderstand me, personally for most of my work on windows I use cygnus (including wget) anyway. However there are still lots of people using Windows NT 4 or even win95/win98, with old compilers, where the compilation won't work without the patch. Even if we place a comment in the source file or the windows/Readme many of those will be discouraged, say those who do have a compiler but aren't really developers (yet) (for example first year CS students with old lab computer compilers). I suppose we could leave that stuff present but commented out, and print a warning when configure.bat --msvc is called. Maybe we could even make that warning conditionally (run cl.exe, use the dos/windows find.exe in order to check the output, if 12.00 echo warning) but that would be even more hacky. have you tried the microsoft visual c++ toolkit 2003? maybe it works. you can download it for free at the following URL: http://msdn.microsoft.com/visualc/vctoolkit2003/ Not yet, but I will certainly. Nevertheless, I think the point is the continue to support existing installation if possble issue, after all VC6 is not free either, and at least one newer commercial VC version has been reported to compile without problems. Those, however, certainly don't support Win95, probably don't Win98/ME or/and NT4 either (didn't yet check though). Personally I feel wget should try to still support that not-so-old compiler platform if possible, even if there are other options, either the direct successor (current VC) or not (free alternatives like cygnus, mingw and borland compilers), in order to keep the development process easily accessible to old installations, in order to have more choices for everybody. Heiko -- -- PREVINET S.p.A. www.previnet.it -- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED] -- +39-041-5907073 ph -- +39-041-5907472 fax
Re: wget 1.10 alpha 2
Herold Heiko [EMAIL PROTECTED] writes: However there are still lots of people using Windows NT 4 or even win95/win98, with old compilers, where the compilation won't work without the patch. Even if we place a comment in the source file or the windows/Readme many of those will be discouraged, say those who do have a compiler but aren't really developers (yet) (for example first year CS students with old lab computer compilers). From my impressions of the Windows world, non-developers won't touch source code anyway -- they will simply use the binary. The really important thing is to make sure that the source works for the person likely to create the binaries, in this case you. Ideally he should have access to the latest compiler, so we don't have to cater to brokenness of obsolete compiler versions. This is not about Microsoft bashing, either: at at least one point Wget triggered a GCC bug; I never installed the (ugly) workaround because later versions of GCC fixed the bug. Also note that there is a technical problem with your patch (if my reading of it is correct): it unconditionally turns on debugging, disregarding the command-line options. Is it possible to save the old optimization options, turn off debugging, and restore the old options? (Borland C seems to support some sort of #pragma push to achieve that effect.) There are other possibilities, too: * Change the Makefile to compile the offending files without optimization, or with a lesser optimization level. Ideally this would be done by configure.bat if it detects the broken compiler version. * Change the Makefile to simply not use optimization by default. This is suboptimal, but would not be a big problem for Wget in practice -- the person creating the binaries would use optimization in his build, which means most people would still have access to an optimized Wget. Not yet, but I will certainly. Nevertheless, I think the point is the continue to support existing installation if possble issue, after all VC6 is not free either, and at least one newer commercial VC version has been reported to compile without problems. Those, however, certainly don't support Win95, probably don't Win98/ME or/and NT4 either (didn't yet check though). You mean that you cannot use later versions of C++ to produce Win95/Win98/NT4 binaries? I'd be very surprised if that were the case! Personally I feel wget should try to still support that not-so-old compiler platform if possible, Sure, but in this case some of the burden falls on the user of the obsolete platform: he has to turn off optimization to avoid a bug in his compiler. That is not entirely unacceptable.
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
# if defined(_POSIX_TIMERS) _POSIX_TIMERS 0 That's fine, if you prefer: ptimer.c:95:46: operator '' has no right operand This doc makes it appear that the unistd.h here does not conform: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html I fear that the test must be beaten into something much uglier, and I have not yet thought of anything good to do the job. SMS.
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
[EMAIL PROTECTED] (Steven M. Schweda) writes: # if defined(_POSIX_TIMERS) _POSIX_TIMERS 0 That's fine, if you prefer: ptimer.c:95:46: operator '' has no right operand I suppose we should then use: #ifdef _POSIX_TIMERS # if _POSIX_TIMERS 0 ... use POSIX timers ... This doc makes it appear that the unistd.h here does not conform: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html Not all platforms supported by Wget conform to POSIX. Since the platforms I use regularly do conform, your testing this is all the more valuable. (But in this case it might even conform -- the spec says IF the symbol is defined, apparently leaving open the possibility of it being undefined.) I fear that the test must be beaten into something much uglier, and I have not yet thought of anything good to do the job. Would the above work for you without errors or warnings?
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
Hrvoje Niksic writes: I suppose we should then use: #ifdef _POSIX_TIMERS # if _POSIX_TIMERS 0 The usual solution to this problem is: #if _POSIX_TIMERS - 0 0 That gets the right answer regardless of whether _POSIX_TIMERS is undefined, defined as nothing, or defined as a number. -Larry Jones In a minute, you and I are going to settle this out of doors. -- Calvin
Re: wget 1.10 alpha 1
Hi, Does anybody know if the security vulnerabilities CAN-2004-1487 and CAN-2004-1488 will be fixed in the new version ? There seems to be at least some truth in the reports (ignore the insulting tone of the reports). http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1487 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1488 Karsten
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
I suppose we should then use: #ifdef _POSIX_TIMERS # if _POSIX_TIMERS 0 Doesn't help. It's defined, but null. Mr, Jones is probably close to the right answer with: #if _POSIX_TIMERS - 0 0 I was looking for a way to make null look like positive, but a little more reading (http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html;) suggests that zero is about as reasonable as anything: If a symbolic constant is defined with the value -1, the option is not supported. Headers, data types, and function interfaces required only for the option need not be supplied. An application that attempts to use anything associated only with the option is considered to be requiring an extension. If a symbolic constant is defined with a value greater than zero, the option shall always be supported when the application is executed. All headers, data types, and functions shall be present and shall operate as specified. If a symbolic constant is defined with the value zero, all headers, data types, and functions shall be present. The application can check at runtime to see whether the option is supported by calling fpathconf(), pathconf(), or sysconf() with the indicated name parameter. Pending a good counter argument, the best way out may be: # if defined(_POSIX_TIMERS) (_POSIX_TIMERS - 0 = 0) Perhaps with a comment describing the (unknown) danger. (Then wait for the next complaint.) Everything's complicated. SMS.
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
[EMAIL PROTECTED] (Larry Jones) writes: Hrvoje Niksic writes: I suppose we should then use: #ifdef _POSIX_TIMERS # if _POSIX_TIMERS 0 The usual solution to this problem is: #if _POSIX_TIMERS - 0 0 Neat trick, thanks. That gets the right answer regardless of whether _POSIX_TIMERS is undefined, defined as nothing, or defined as a number. I guess the defined as nothing case was losing. BTW does the above trick work with KR preprocessors?
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
[EMAIL PROTECTED] (Steven M. Schweda) writes: Mr, Jones is probably close to the right answer with: #if _POSIX_TIMERS - 0 0 I was looking for a way to make null look like positive, but a little more reading (http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html;) suggests that zero is about as reasonable as anything: If we supported _POSIX_TIMERS == 0, we'd need to check with sysconf whether they are available and fall back to gettimeofday if not. That would complicate the code because the timer implementation could no longer be chosen at compile-time. Since we must support gettimeofday anyway, I opted to use _POSIX_TIMERS only if they are always, and to just use gettimeofday (which isn't really that bad) otherwise. Pending a good counter argument, the best way out may be: # if defined(_POSIX_TIMERS) (_POSIX_TIMERS - 0 = 0) Checking for =0 without the sysconf check in the ==0 case seems asking for trouble.
Re: Build problem: ptimer.c (CVS 1.7), gcc 3.4.3, Tru64 UNIX V5.1B
Hrvoje Niksic writes: I guess the defined as nothing case was losing. BTW does the above trick work with KR preprocessors? Yep. (That's why it uses - 0 rather than + 0, the latter is only valid for ANSI C.) -Larry Jones It's no fun to play games with a poor sport. -- Calvin
Re: wget 1.10 alpha 1
Karsten Hopp [EMAIL PROTECTED] writes: Does anybody know if the security vulnerabilities CAN-2004-1487 and CAN-2004-1488 will be fixed in the new version ? Yes on both counts. There seems to be at least some truth in the reports (ignore the insulting tone of the reports). http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1487 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1488 I've read them. The first one is fairly improbable because it requires special DNS setup for .. to resolve to an IP address. The second one poses a real problem, which I simply never considered. I'm not sure if either issue is critical enough to warrant a 1.9.2 release. The proximity of 1.10, which fixes both problems, makes it unnecessary.
frames
A website uses frames, and when I view it in Explorer, it has the URL https://123.456.89.01/blabla.nsf/HOBART?opeNFRAMESETand a bunch of PDF files in two of the frames. When I try to recursively download this web site, I don`t get the files. I am using the following command: wget -nc -x -r -l10 -p -E -np -t10 -k -o frames.log -nv -A*.* -H "https://123.456.89.01/blabla.nsf/HOBART?opeNFRAMESET" The log file looks like: 17:54:41 URL:https://123.456.89.01/blabla.nsf/HOBART?opeNFRAMESET [565/565] - "123.456.89.01/blabla.nsf/HOBART?opeNFRAMESET.html" [1] FINISHED --17:54:41--Downloaded: 565 bytes in 1 files Does wget work with frames? Do I need to do something different? Thanks, Alan
Re: frames
Alan Thomas [EMAIL PROTECTED] writes: A website uses frames, and when I view it in Explorer, it has the URL https://123.456.89.01/blabla.nsf/HOBART?opeNFRAMESET and a bunch of PDF files in two of the frames. When I try to recursively download this web site, I don`t get the files. [...] Does wget work with frames? Do I need to do something different? Wget should work with frames. Maybe the site is using JavaScript to load the frame contents?
