RE: [WINDOWS] Missing DLL error
Something of a deja vu here. IF you got your copy from http://space.tin.it/computer/hherold or directly from ftp://ftp.sunsite.dk/projects/wget/windows , you need to get the ssl libraries from the same place, as stated on there site: 1.8.2 2002/05/29 Source (http), source (ftp), binary (http), binary (ftp) for wget 1.8.2, ssl enabled (get the ssl libraries above). and SSL Libraries 2002/05/20 ssllibs (http), ssllibs (ftp). Source at www.openssl.org, openssl-0.9.6d.tar.gz. ANY wget binary compiled with ssl need these. You'll need to drop the libraries somewhere in your PATH or c:\Winnt or c:\Windows or whatever suits your installation in order to make https connections work If you got the ssl library from somewhere else it's likely it won't work. The binary for 1.8.1 from those places doesn't have ssl enabled, no library is required, on the other hand https connections won't work either. Heiko Herold -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907472 -- ITALY > -Original Message- > From: Gianfranco Boggio-Togna [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 03, 2002 6:23 AM > To: [EMAIL PROTECTED] > Subject: [WINDOWS] Missing DLL error > > > When I run wget 1.8.2 (with just "-V") I get a message stating that > LIBAY32.DLL cannot be found (wget 1.8.1 is OK). > > -- >Gianfranco Boggio-Togna >Milano (Italy) >
[WINDOWS] Missing DLL error
When I run wget 1.8.2 (with just "-V") I get a message stating that LIBAY32.DLL cannot be found (wget 1.8.1 is OK). -- Gianfranco Boggio-Togna Milano (Italy)
Re: http://bugs.debian.org/148583 "Internationalization isincomplete - only translation provided"
Noel Koethe <[EMAIL PROTECTED]> writes: > "The internationalization of wget seem incomplete. It is translated, but not > properly localized, which can easily be seen here: > > Längd: 34,885,632 [audio/mpeg] > 100%[>] 34,885,632 True. I intended the thousand separator to be a simple visual aid; I didn't even think about the "proper" separators and how this should be done in different locales. Most of Wget avoids the localization issues by using ISO 8601-like formats for dates, and sticking to the C locale when printing numbers. So far noone has complained. At the risk of sounding the wrong way, I'd like to ask: is this really so much of a problem? Are other command-line programs using thousands separators, and doing it correctly, so that Wget stands apart? I'd really like the basic output of numbers not to depend on the locale -- if such a thing is acceptable.
Re: wget 1.8.1 problem.
This crash seems to be gettext-related. What does `ldd wget' say?
Re: Bug ?
I don't know why Wget dumps core on startup. Perhaps a gettext problem? I have seen reports of failure on startup on Solaris, and it strikes me that Wget could have picked up wrong or inconsistent gettext. Try unsetting the locale-related evnironment variables and seeing if Wget works then.
Re: HTTP /1.1 500 Internal Server Error
Hack Kampbjørn <[EMAIL PROTECTED]> writes: > But I'm not sure wget should do [HTML de-quoting] for URLs on the > cmd line or in a non-HTML file. I'm pretty sure that it shouldn't. HTML unquoting only makes sense in the context of HTML. That's how the browsers behave, as well -- typing "&" in the location field will not cause it to be dequoted.
Bug ?
Dear [EMAIL PROTECTED], Please pardon the sudden e-mail. My name is Sekigawa. I am a Network SE in Japan. Only a few days ago, I installed wget-1.8.2 and running on Solaris2.6. But wget-1.8.2 dumped core file before connection. See also below, -- --13:30:45-- http://fly.cc.fer.hr:80/ $B"M(B'index.html' Segmentation Falut(Core Dump) -- When it was running "./configure", it showed WARNING message about gcc version on Solaris System. I tried to install and run other wget version (1.7, 1.6), in addition, to do wget-1.8.1-sol26-sparc-local.gz. Every wget versions dumped core file before connection! Environment related to gcc etc on my Solaris2.6 System is so wrong ??? or what, Is this wget's bug ??? Please let me know, when you get time. I would greately appreciate any help you could give me. 2002/06/03 Best Regards, Sekigawa Ai __ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/
Re: Wget 1.8.2-pre3 ready for testing
On Tue, 28 May 2002, Hrvoje Niksic wrote: > Doug Kaufman <[EMAIL PROTECTED]> writes: > > > > This doesn't work "out of the box" for DJGPP or for Cygwin. Appended > > is a patch to fix most of the problems. > > Thanks for the comments and the patch. The patch will most likely not > make into the 1.8.2 release. I didn't really expect it to go into a near-final release. > Patching configure is a bad idea, as that file is auto-generated. > Patches should go either to configure.in, or Autoconf should be fixed. The patch for Cygwin worked, but really wasn't the appropriate fix. Appended is a revised patch, against the 1.8.2 release. I also included the DJGPP fix for .netrc, which I forgot in the first patch. This was tested using configure generated by autoconf from the patched configure.in. > As for the DJGPP support such as `msdosify', I'm really not sure > whether that should go in. I certainly don't want to support the > broken 8+3 file systems. It's just too painful, and DOS isn't all > that used anymore. I am not sure that I follow the reasoning here. DOS is alive and well with almost all GNU programs ported to DOS and most compiling under DOS from the main GNU source code. Once bash and gcc were ported, all the rest followed. Do you really want wget to be one of the few GNU programs which don't support the DOS operating system with the GCC compiler? The algorithms for adjusting filenames to 8+3 were worked out years ago. As noted in the patch, I just borrowed this code from the DOS port of GNU tar. Networking code had been a problem, but with watt-32 development this has been much easier the last few years. As the main person distributing the DOS binary for the lynx browser, I can assure you (from the downloads and from requests for assistance that I receive), that there are still lots of DOS users out there looking for software to use over the net. Some are visually impaired and some are from parts of the world that can't afford newer desktop computers. Others just prefer the DOS operating system. Doug --- wget-1.8.2/configure.in.orig2002-05-17 19:05:10.0 -0800 +++ wget-1.8.2/configure.in 2002-06-01 05:41:02.0 -0800 @@ -138,6 +138,7 @@ dnl Might also be erelevant for DJGPP. dnl case "$host_os" in + *msdosdjgpp) exeext='.exe';; *win32) exeext='.exe';; *) exeext='';; esac --- wget-1.8.2/djconfig.sh.orig 2002-06-01 05:21:22.0 -0800 +++ wget-1.8.2/djconfig.sh 2002-06-01 05:21:22.0 -0800 @@ -0,0 +1,15 @@ +#!/bin/sh +# This file, when run from a bash shell in DOS, will configure wget +# for DJGPP. Be sure to set the environment variable WATT_ROOT first, +# pointing to your WATT-32 distribution. Remove "-lintl" and "-liconv" +# if you don't have the gettext package installed. Remove "-lwmemu" if +# you don't want to link with the wmemu floating point emulator. Remove +# "--with-ssl" if you don't have openssl installed. This file must have +# unix-style end of lines (LF), not DOS-style (CR LF). + +auto_cflags=1 \ +CFLAGS="-W" \ +CPPFLAGS="-I$WATT_ROOT/inc" \ +LIBS="-L$WATT_ROOT/lib -lwatt -lintl -liconv -lwmemu" \ +./configure \ +--with-ssl --- wget-1.8.2/Makefile.in.orig 2002-05-17 19:05:10.0 -0800 +++ wget-1.8.2/Makefile.in 2002-06-01 05:21:22.0 -0800 @@ -153,7 +153,7 @@ $(RM) *~ *.bak $(DISTNAME).tar.gz distclean-top: clean-top - $(RM) Makefile config.status config.log config.cache stamp-h + $(RM) Makefile config.status config.log config.cache libtool stamp-h realclean-top: distclean-top $(RM) configure --- wget-1.8.2/src/config.h.in.orig 2002-05-17 19:05:14.0 -0800 +++ wget-1.8.2/src/config.h.in 2002-06-01 05:24:28.0 -0800 @@ -36,7 +36,9 @@ /* AIX requires this to be the first thing in the file. */ #ifdef __GNUC__ +#ifndef __CYGWIN__ # define alloca __builtin_alloca +#endif /* __CYGWIN__ */ #else # if HAVE_ALLOCA_H # include --- wget-1.8.2/src/ftp.c.orig 2002-05-17 19:05:16.0 -0800 +++ wget-1.8.2/src/ftp.c2002-06-01 05:21:24.0 -0800 @@ -43,6 +43,9 @@ #include #include #include +#ifdef __DJGPP__ +#include +#endif /* __DJGPP__ */ #include "wget.h" #include "utils.h" @@ -1352,7 +1355,7 @@ follow them. */ if (!opt.retr_symlinks) { -#ifdef HAVE_SYMLINK +#if defined(HAVE_SYMLINK) && defined(S_IFLNK) if (!f->linkto) logputs (LOG_NOTQUIET, _("Invalid name of the symlink, skipping.\n")); @@ -1393,7 +1396,7 @@ logprintf (LOG_NOTQUIET, _("Symlinks not supported, skipping symlink `%s'.\n"), con->target); -#endif /* not HAVE_SYMLINK */ +#endif /* not HAVE_SYMLINK or not S_IFLNK */ } else/* opt.retr_symlinks */ { --- wget-1.8.2/src/gen_sslfunc.c.orig 2002-05-17 19:14:48.0 -0800 +++ wget-1.8
Patch for recovering from proxy failure
I have posted a patch to help recover from proxy failures where the proxy adds a HTML document with error message to aborted download now twice to wget-patches. There has been no reaction of any kind. Could someone tell me what is happening? Am I doing something so wrong it deserves no reply? The patch should be available from [EMAIL PROTECTED] or http://kotisivu.mtv3.fi/oma/marko.kohtala/wget-continue.patch and ChangeLog from http://kotisivu.mtv3.fi/oma/marko.kohtala/wget-continue-changelog.patch -- Marko Kohtala Maksuton sähköposti aina käytössä http://luukku.com Kuukausimaksuton MTV3 Internet-liittymä www.mtv3.fi/liittyma
Re: HTTP /1.1 500 Internal Server Error
Mark Bucciarelli wrote: > > I am having trouble wgetting a samsung printer driver from their site. Every > time I try, I immediately get an HTTP/1.1 500 Internal Server Error. The > web browser initiates the download properly when I click on the link from the > referer page. > > Here is the command I am running (I don't have a .wgetrc): > > wget --debug > >--referer="http://www.samsungelectronics.com/printer/support/downloads/400329_844_file4.html"; > >"http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz"; > > and here is the debug output: This seems to be yet another encoding problem. I have no problem if I change the '&' to '&'. IIRC URLs found in a HTML page should be HTML decoded. A simple test (wget -F -i URL.html) shows that wget does this. But I'm not sure wget should do it for URLs on the cmd line or in a non-HTML file. In the past we had a lot of problems with wget being overzealously {en|de}coding URLs. $ wget "http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz"; --15:20:35-- http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz => `Downloader@path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz' Connecting to 211.45.27.253:80... connected. HTTP request sent, awaiting response... 200 OK Length: 28,864,218 [application/octet-stream] Last-modified header missing -- time-stamps turned off. --15:20:36-- http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz => `Downloader@path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz' Connecting to 211.45.27.253:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/octet-stream] [ <=> ] 1,257,472 25.53K/s > Thanks for a great tool! And thank you for reading the instructions and actually including debug output ! > > Mark -- Med venlig hilsen / Kind regards Hack Kampbjørn
HTTP /1.1 500 Internal Server Error
I am having trouble wgetting a samsung printer driver from their site. Every time I try, I immediately get an HTTP/1.1 500 Internal Server Error. The web browser initiates the download properly when I click on the link from the referer page. Here is the command I am running (I don't have a .wgetrc): wget --debug --referer="http://www.samsungelectronics.com/printer/support/downloads/400329_844_file4.html"; "http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz"; and here is the debug output: DEBUG output created by Wget 1.8.1 on linux-gnu. --08:21:58-- http://211.45.27.253/servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz => `Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz' Connecting to 211.45.27.253:80... connected. Created socket 3. Releasing 0x8071fe0 (new refcount 0). Deleting unused 0x8071fe0. ---request begin--- GET /servlet/Downloader?path=%2Fprinter%2Fsupport%2Fdownloads%2Fattach_file%2F20020516175051spp-1.0.2.i386.tar.gz&realname=spp-1.0.2.i386.tar.gz HTTP/1.0 User-Agent: Wget/1.8.1 Host: 211.45.27.253 Accept: */* Connection: Keep-Alive Referer: http://www.samsungelectronics.com/printer/support/downloads/400329_844_file4.html ---request end--- HTTP request sent, awaiting response... HTTP/1.1 500 Internal Server Error Server: Microsoft-IIS/5.0 Date: Sun, 02 Jun 2002 12:07:47 GMT Connection: keep-alive Connection: Keep-alive Content-Type: text/html Content-Length: 1565 Registered fd 3 for persistent reuse. Closing fd 3 Releasing 0x8072818 (new refcount 0). Deleting unused 0x8072818. Invalidating fd 3 from further reuse. 08:21:59 ERROR 500: Internal Server Error. Thanks for a great tool! Mark