Re: [bug #64808] When I use wget to download some files from a web server, files with russian names do not get proper names

> Date: Fri, 17 Nov 2023 20:34:37 +0100 > From: grafgrim...@gmx.de > > I use Linux and so not exe files. I use Gentoo Linux. > > Command line example: > One line (wget and the url): > > wget > http://releases.mozilla.org/pub/firefox/releases/119.0.1/source/firefox-119.0.1.source.tar.xz > >

[bug #60287] Windows recursive download escapes utf8 URLs twice

Follow-up Comment #12, bug #60287 (project wget): You are welcome to send patches which would implement what you think should be the correct behavior in Wget. At the time, based on my study of the Wget sources and its basic design of fetching Web pages, my conclusion was that the only reliable

[bug #60287] Windows recursive download escapes utf8 URLs twice

Follow-up Comment #10, bug #60287 (project wget): Without converting charsets, it would be difficult to rely on certain library functions and support certain features. For example, locale-dependent C library functions work only with the locale's encoding, and will produce wrong results if

[bug #60287] Windows recursive download escapes utf8 URLs twice

Follow-up Comment #8, bug #60287 (project wget): > Is this because wget first downloads the html file and then reads the contents off disk No. It's because Wget downloads the pages you told it to, and saves them as disk files. Any links in the downloaded pages that lead to other pages produce

[bug #60287] Windows recursive download escapes utf8 URLs twice

Follow-up Comment #6, bug #60287 (project wget): > Isn't the encoding specified in the HTTP header? Not the local one. (And not every page you download has these headers, so the remote one isn't always known, either.) You must specify the local encoding, especially on MS-Windows, because

[bug #60287] Windows recursive download escapes utf8 URLs twice

Follow-up Comment #4, bug #60287 (project wget): Why does this feel like a bug to you? How can Wget be expected to guess the correct encoding, if you don't tell it? ___ Reply to this item at:

[bug #60287] Windows recursive download escapes utf8 URLs twice

Follow-up Comment #2, bug #60287 (project wget): What was the locale on the GNU/Linux machine, where this "just works"? I'm guessing it was a UTF-8 locale, in which case I'd try the same with a different locale. I think you must use --remote-encoding=UTF-8 (and perhaps also a suitable

Re: Error SSL al ejecutar desde Windows

> From: Tim Rühsen > Date: Sat, 13 Feb 2021 18:23:31 +0100 > > Try without " or leave away the spaces between these and the URL. > (Possibly I am misguided but your mailers line breaks.) > > wget --no-check-certificate >

Re: Confusing "Success" error message

> Date: Fri, 8 Nov 2019 17:29:21 +0100 > From: "Andries E. Brouwer" > Cc: "Andries E. Brouwer" , tim.rueh...@gmx.de, > ftu...@fastmail.fm, bug-wget@gnu.org > > Did you read the line "a function that succeeds is allowed to change errno"? Yes, but that's against every library whose

Re: Confusing "Success" error message

> Date: Fri, 8 Nov 2019 16:47:30 +0100 > From: "Andries E. Brouwer" > Cc: "Andries E. Brouwer" , tim.rueh...@gmx.de, > ftu...@fastmail.fm, bug-wget@gnu.org > > On Fri, Nov 08, 2019 at 04:34:10PM +0200, Eli Zaretskii wrote: > > > &g

Re: Confusing "Success" error message

> Date: Fri, 8 Nov 2019 15:03:21 +0100 > From: "Andries E. Brouwer" > Cc: Francesco Turco , bug-wget@gnu.org, > "Andries E. Brouwer" > > > Libc functions only touch errno if there *is* an error > > Libc functions are free to call other functions internally, > and such internal calls may fail

Re: [Bug-wget] Problem downloading with RIGHT SINGLE QUOTATION MARK (U+2019) in filename

> From: Cameron Tacklind > Date: Thu, 10 Oct 2019 20:31:02 -0700 > > The error is pretty clearly an encoding conversion issue, going from UTF-8, > assumed to be CP1252, converting into UTF-8, which becomes wrong. I think you need to tell Wget that the page encoding is UTF-8, by using the

Re: [Bug-wget] Wget on Windows handling of wildcards

> From: Sam Habiel > Date: Wed, 6 Jun 2018 08:27:44 -0400 > Cc: bug-wget@gnu.org > > Is there a valid argument to be made that some arguments for wget > should not be expanded, like accept and reject? Probably. The problem is that wildcard expansion of the command line doesn't understand the

Re: [Bug-wget] Wget on Windows handling of wildcards

> From: Sam Habiel > Date: Tue, 5 Jun 2018 14:16:27 -0400 > > I have a wget command that has a -A flag that contains a wildcard. > It's '*.DAT'. That works fine on Linux. I am trying to get the same > thing to run on Windows, but *.DAT keeps getting expanded by wget (cmd > does no expansion

[Bug-wget] Run-time issues with Wget2 1.99.1 built with MinGW

> From: Tim Rühsen > Date: Tue, 1 May 2018 15:15:26 +0200 > > GNU Wget2 is the successor of GNU Wget, a file and recursive website > downloader. > > Designed and written from scratch it wraps around libwget, that provides > the basic functions needed by a web client. > >

[Bug-wget] Build issues when building Wget2 1.99.1 with MinGW

> From: Tim Rühsen > Date: Tue, 1 May 2018 15:15:26 +0200 > > GNU Wget2 is the successor of GNU Wget, a file and recursive website > downloader. > > Designed and written from scratch it wraps around libwget, that provides > the basic functions needed by a web client. > >

Re: [Bug-wget] Patch: Make url_file_name also convert remote path to local encoded

> From: Tim Rühsen > Date: Sun, 12 Nov 2017 14:50:47 +0100 > Cc: YX Hao > > As I understand, the second patch is still in discussion with Eli. Since I do > not have Windows, I can't help you here. Though what I saw from the > discussion, you address a

Re: [Bug-wget] Patch: Fix printing mutibyte characters as unprintable characters on Windows

> From: "YX Hao" > Cc: > Date: Sun, 5 Nov 2017 23:01:22 +0800 > > And I can tell you that 'GetConsoleOutputCP' returns the codepage as command > 'chcp'. It is right. The gnu 'vsnprintf' doesn't work right with 'setlocale' > omitted. I guess this means

Re: [Bug-wget] Patch: Fix printing mutibyte characters as unprintable characters on Windows

> From: "YX Hao" > Cc: > Date: Sun, 5 Nov 2017 23:01:22 +0800 > > >> '_getmbcp' is used > > Maybe the problem is that the codepage used for the console output is > > different from the system's ANSI codepage? What does GetConsoleOutputCP > > return in the

Re: [Bug-wget] Patch: Fix printing mutibyte characters as unprintable characters on Windows

> From: "YX Hao" <lifenjoi...@163.com> > Cc: "'Eli Zaretskii'" <e...@gnu.org> > Date: Fri, 3 Nov 2017 20:14:02 +0800 > > Second, as my test, 'setlocale' is needed for the gnu printf related > functions to work correctly on mutibyte cha

Re: [Bug-wget] Patch: Fix printing mutibyte characters as unprintable characters on Windows

> From: "YX Hao" > Date: Thu, 2 Nov 2017 21:09:31 +0800 > > During my daily use, I've found a few small bugs and made the patches. > I will email them in standalone topics. Patch is attached. > > I made the patch on Windows. I think it shouldn't break anything on other >

Re: [Bug-wget] Wget keeps crashing on me

> From: William Higgs > Cc: , > 'Jernej Simončič' > Date: Sun, 14 May 2017 21:17:02 -0400 > > Hey guys. So while I was doing some research, I found the following post > located at >

Re: [Bug-wget] Wget keeps crashing on me

> From: William Higgs > Date: Sun, 14 May 2017 12:13:58 -0400 > > So just to be clear, you want me to use an older release of wget? No, I'm just saying that the version I built worked without crashing. You may wish to try it; if it works on your system, it might mean the

Re: [Bug-wget] Wget keeps crashing on me

> From: William Higgs > Date: Sun, 14 May 2017 10:27:12 -0400 > > And I saw that you had stated that it was working on Windows 7, which > further convinces me that it is probably a windows 10 thing. I originally > thought this was the case because, while the faulting

Re: [Bug-wget] Wget keeps crashing on me

> From: William Higgs > Date: Sun, 14 May 2017 10:23:35 -0400 > > The txt file contains the output from the command "wget --version". Maybe I'm missing something, but I don't see that. All I see is this: Description : Faulting application name: wget.exe,

Re: [Bug-wget] Wget keeps crashing on me

> From: William Higgs > Date: Sat, 13 May 2017 17:37:13 -0400 > > So this may have nothing to do with wget (probably very likely, as Windows > 10 creators update continues to be a very large thorn in my side), but wget > keeps crashing when I run the attached bat file

Re: [Bug-wget] GSoC Project | Design and Implementation of a Framework for Plugins

> Date: Tue, 21 Mar 2017 02:29:20 +0700 > From: Didik Setiawan > > > One way to implement plugins is via libdl (dlopen(), ...), and that is what > > I > > have in mind. That is not perfectly portable, but our first goal will be > > systems that support dlopen(). > >

Re: [Bug-wget] Vulnerability Report - CRLF Injection in Wget Host Part

> From: Tim Ruehsen > Date: Mon, 06 Mar 2017 10:17:25 +0100 > Cc: Orange Tsai > > Thanks, just pushed a commit, not allowing control chars in host part. Hmm... is it really enough to reject only ASCII control characters? Maybe we should also reject

Re: [Bug-wget] Fwd: PATCH: bugs 20369 and 20389

> From: Vijo Cherian > Date: Fri, 3 Mar 2017 11:33:05 -0800 > Cc: bug-wget@gnu.org > > bool > file_exists_p (const char *filename, file_stats_t *fstats) > { > struct stat buf; > > #if defined(WINDOWS) || defined(__VMS) > return stat (filename, ) >= 0; > #else This

Re: [Bug-wget] Fwd: PATCH: bugs 20369 and 20389

> From: Vijo Cherian > Date: Thu, 2 Mar 2017 18:47:11 -0800 > > Changes > - Bug #20369 - Safeguards against TOCTTOU > Added safe_fopen() and safe_open() that checks to makes sure the file > didn't change underneath us. > - Bug #20389 - Return error from

Re: [Bug-wget] patch: Improve the rolling file name length for downloading progress image when without NLS

> Date: Fri, 17 Feb 2017 14:44:02 +0100 > From: "Andries E. Brouwer" <andries.brou...@cwi.nl> > Cc: "Andries E. Brouwer" <andries.brou...@cwi.nl>, tim.rueh...@gmx.de, > bug-wget@gnu.org, lifenjoi...@163.com > > On Fri, Feb 17, 2017 at 0

Re: [Bug-wget] patch: Stored file name coversion logic correction

> Date: Thu, 16 Feb 2017 12:42:23 +0800 (CST) > From: "YX Hao" > > I downloaded the 'mbox format' original, and found out the reason why you > can't reproduce the issue. > The non-ASCII characters you use is encoded in "iso-8859-1" in your email, > and should be displayed

Re: [Bug-wget] [PATCH] utils: rename base64_{encode,decode}

> From: Rahul Bedarkar > Date: Thu, 15 Dec 2016 12:57:16 +0530 > > In case of static build, all symbols are visible. Since GnuTLS is static > library, which is just archive of object files, linking happens at > caller end i.e. wget, linker don't know what to

Re: [Bug-wget] Query about correcting for DST with Wget

> From: Tim Ruehsen > Date: Tue, 15 Nov 2016 10:41:40 +0100 > > > If we care about this, we could have a private implementation of > > utimes in mswindows.c, which would DTRT in the use cases needed by > > Wget. > > Wget uses utime() if available. This function is not

Re: [Bug-wget] Query about correcting for DST with Wget

> Date: Sun, 13 Nov 2016 21:39:32 +0100 > From: Jernej Simončič <jernej|s-w...@eternallybored.org> > > On Sunday, November 13, 2016, 19:53:06, Eli Zaretskii wrote: > > > Does "while DST is in effect" mean that you download the file when DST > >

Re: [Bug-wget] Query about correcting for DST with Wget

> Date: Sun, 13 Nov 2016 19:10:57 +0100 > From: Jernej Simončič > > I'm not sure if this is a problem with wget, Windows or the server > hosting the file, but I observed this happening with > - while DST is in effect,

Re: [Bug-wget] Query about correcting for DST with Wget

> From: "Tim" > Date: Thu, 10 Nov 2016 19:26:45 - > > I would be very grateful for any help with an issue I am having with > downloading files from a website using Version 1.11.4.3287 of Wget on a > Windows XP computer. That's a very old version of Wget. > When I use

Re: [Bug-wget] Fwd: Re: [PATCH v3] bug #45790: wget prints it's progress even when background

> From: "Wajda, Piotr" > Date: Wed, 19 Oct 2016 12:18:13 +0200 > > For CTRL+Break we could probably go to background on windows by forking > process using current fake_fork method. Child process should be then > started with -c and -b. Could be, although it'd be a strange

Re: [Bug-wget] [PATCH v3] bug #45790: wget prints it's progress even when background

> From: "Wajda, Piotr" > Date: Wed, 19 Oct 2016 11:57:06 +0200 > > My only confusion was that during testing on windows, when sending > CTRL+C or CTRL+Break it immediately terminates, which is basically what > I think it should do for CTRL+C. Not sure about CTRL+Break.

Re: [Bug-wget] strerror() on Win32

> From: Gisle Vanem > Date: Thu, 13 Oct 2016 22:42:03 +0200 > > I think I've mentioned earlier; the troubles with strerror() > returning "Unknown error" for seemingly common 'errno' values. > > I hit me today, when connection to my ftp-hosting service. From > the Wsock-trace

Re: [Bug-wget] [PATCH v3] bug #45790: wget prints it's progress even when background

> From: losgrandes > Date: Thu, 6 Oct 2016 09:47:01 +0200 > > Fortunately I tested wget.exe in normal mode and background mode (-b). Was ok. > Unfortunately I haven't tested wget.exe with CTRL+Break/CTRL+C (is it really > works on windows?). Yes, CTRL-C/CTRL-BREAK should

Re: [Bug-wget] [PATCH v2] bug #45790: wget prints it's progress even when background

> Cc: Eli Zaretskii <e...@gnu.org> > From: "pwa...@gmail.net.pl" <pwa...@gmail.net.pl> > Date: Sun, 2 Oct 2016 21:54:58 +0200 > > Is there a instruction on how to compile current wget version on windows? Nothing special, just "./configure &&

Re: [Bug-wget] wget for windows - current build?

> From: Tim Rühsen > Cc: ge...@mweb.co.za > Date: Sat, 01 Oct 2016 20:12:28 +0200 > > If you like to create a README.windows maybe with (basic) explanations on how > to build wget on Windows plus pointers to your port(s), we include it into > the > project. That's okay

Re: [Bug-wget] wget for windows - current build?

> From: Tim Rühsen > Cc: ge...@mweb.co.za > Date: Sat, 01 Oct 2016 18:10:26 +0200 > > > > It shouldn't be too hard to write a script that cross-compiles wget and > > > some dependencies via mingw. But would such an .exe really work on a real > > > Windows machine ? > > > >

Re: [Bug-wget] wget for windows - current build?

> From: Tim Rühsen > Cc: "ge...@mweb.co.za" > Date: Sat, 01 Oct 2016 13:04:25 +0200 > > It shouldn't be too hard to write a script that cross-compiles wget and some > dependencies via mingw. But would such an .exe really work on a real Windows > machine ?

Re: [Bug-wget] wget for windows - current build?

> Date: Fri, 30 Sep 2016 16:52:55 +0200 (SAST) > From: "ge...@mweb.co.za" > > So, is there a "secret" new place hosting a newer version for Windows? Or is > the 1.11 on sourceforge actually okay? And - while I am already asking all > these stupid questions - would that

Re: [Bug-wget] [PATCH v2] bug #45790: wget prints it's progress even when background

> From: Piotr Wajda > Date: Fri, 30 Sep 2016 09:51:37 +0200 > > Hi, Reworked recent patch to behave correctly on fg and bg. Now user can > switch from fg to bg and vice versa and wget will select fd accordingly. Thanks. > + /* Initialize this values so we don't have to

Re: [Bug-wget] [PATCH 20/25] New option --metalink-index to process Metalink application/metalink4+xml

> From: Tim Ruehsen > Cc: mehw.is...@inventati.org, bug-wget@gnu.org > Date: Fri, 16 Sep 2016 11:15:31 +0200 > > > So if wget needs to create or open such files, it needs to replace the > > colon with some other character, like '!'. > > That is what I meant with 'Wget has

Re: [Bug-wget] [PATCH 20/25] New option --metalink-index to process Metalink application/metalink4+xml

> From: Tim Ruehsen > Date: Fri, 16 Sep 2016 10:15:17 +0200 > Cc: bug-wget@gnu.org > > > *name + ref -> result > > - > > NULL + "foo/C:D:file" -> "file" [bare basename] > > "foobar"

Re: [Bug-wget] [PATCH 09/25] Enforce Metalink file name verification, strip directory if necessary

> From: Tim Ruehsen > Date: Mon, 12 Sep 2016 13:00:32 +0200 > > > + char *basename = name; > > + > > + while ((name = strstr (basename, "/"))) > > +basename = name + 1; > > Could you use strrchr() ? something like > > char *basename = strrchr (name, '/'); > > if

Re: [Bug-wget] Wget - acess list bypass / race condition PoC

> From: Giuseppe Scrivano > Date: Sun, 21 Aug 2016 15:26:58 +0200 > Cc: "bug-wget@gnu.org" , > Dawid Golunski , > "kseifr...@redhat.com" > > #else /* def __VMS */ > - *fp = fopen

Re: [Bug-wget] [PATCH] wget: Add --ssh-askpass support

> From: j...@wxcvbn.org (Jeremie Courreges-Anglas) > Cc: "Liam R. Howlett" , bug-wget@gnu.org > Date: Sat, 23 Jul 2016 21:24:33 +0200 > > > This implementation is unnecessarily non-portable ('fork' doesn't > > exist on some supported platforms). I suggest to use a

Re: [Bug-wget] [PATCH] wget: Add --ssh-askpass support

> From: "Liam R. Howlett" > Date: Fri, 22 Jul 2016 20:24:05 -0400 > Cc: liam.howl...@windriver.com > > This adds the --ssh-askpass option which is disabled by default. Thanks. > + > +/* Execute external application SSH_ASKPASS which is stored in > opt.ssh_askpass >

Re: [Bug-wget] [PATCH] Trivial changes in HSTS

> From: Gisle Vanem > Date: Fri, 17 Jun 2016 22:50:27 +0200 > > > +static bool > > +hsts_file_access_valid (const char *filename) > > +{ > > + struct_stat st; > > + > > + if (stat (filename, ) == -1) > > +return false; > > + > > + return !(st.st_mode & S_IWOTH) && S_ISREG

Re: [Bug-wget] retrieval failure:Forbidden? for UTF-8-URL in wget that works on FF and IE

> Date: Wed, 08 Jun 2016 11:47:46 -0700 > From: "L. A. Walsh" > > I tried: > > wget "http://translate.google.com/#ja/en/クイーンズブレイド・メインテーマＢ; > > But get a an Error "403: Forbidden" (tried w/ and w/o proxy) -- same. On what OS and with which version of wget?

Re: [Bug-wget] Progress bar on MS-Windows

> From: Gisle Vanem > Date: Tue, 7 Jun 2016 09:00:43 +0200 > > Compare the attached image wget-progress-1.png: > wget --show-progress --quiet -np -r www.watt-32.net/watt-doc/ > > VS wget-progress-2.png: > wget --show-progress --quiet --limit-rate=2k -np -r >

Re: [Bug-wget] Progress bar on MS-Windows

> Date: Sat, 04 Jun 2016 13:40:12 +0300 > From: Eli Zaretskii <e...@gnu.org> > > > Here's a build as of commit 7c0752c4cb6575c6720d6e2d4bf4eda61b63e0f1: > > https://eternallybored.org/misc/wget/test/wget.exe > > Thanks, will try it. Finally had an opportunity

Re: [Bug-wget] Progress bar on MS-Windows

> Date: Sat, 4 Jun 2016 11:08:18 +0200 > From: Jernej Simončič <jernej|s-w...@eternallybored.org> > > On Saturday, June 4, 2016, 10:27:56, Eli Zaretskii wrote: > > > Sorry, no. Not unless someone will be kind enough to produce a > > complete tarball. Bui

Re: [Bug-wget] Progress bar on MS-Windows

> Date: Wed, 1 Jun 2016 10:28:35 +0200 > From: Darshit Shah > Cc: bug-wget@gnu.org > > Can you please try with the latest HEAD once? As far as I am aware, all > the off-by-one errors have been fixed. Sorry, no. Not unless someone will be kind enough to produce a complete

[Bug-wget] Progress bar on MS-Windows

Running wget from the Windows cmd window, I see that we write 1 column too many, when we display "eta XXm YYs" -- this causes the next progress bar be displayed on the next screen line. So I came up with a small patch below, in the Windows specific portion of determine_screen_width. Does anyone

Re: [Bug-wget] wget IRI test failures on Mac OS X

> From: Ryan Schmidt > Date: Wed, 18 May 2016 02:39:56 -0500 > Cc: bug-wget@gnu.org > > Thanks Eli. I tried the latest commit from April 2016, > 42cc84b6b6cceeb146a668797ceaafe60743ce6d, and the IRI tests still failed: Does OS X have a function that can compare equal

Re: [Bug-wget] Wget 1.17.1 bug?

> Date: Tue, 17 May 2016 11:22:25 +0300 > From: "Zeroes & Ones" > > I not compiled himself, i use binaries installed used setup-x86.exe (v2.874 > 32 bit) > > chosen site: > cygwin.mirror.constant.com > > trouble reproduced 100% > > wget -V > > GNU Wget 1.17.1 built on

Re: [Bug-wget] wget IRI test failures on Mac OS X

> From: Ryan Schmidt > Date: Thu, 12 May 2016 23:52:08 -0500 > Cc: Micah Cowan > > Hello, just wanted to gently remind you that this bug in the wget test suite > running on OS X that I reported in 2009 with wget 1.12 still exists today > with wget

Re: [Bug-wget] Wget 1.17.1 bug?

> Date: Mon, 16 May 2016 10:24:25 +0300 > From: "Zeroes & Ones" > > i update Wget 1.11.4 to latest 1.17.1 and i have troubles > > output file have wrong permission on NTFS (checked on W2008R2, Win8.1) > > > for example > wget.exe

[Bug-wget] [bug #47701] wget 1.17.1 fails to convert from percent encoding to unicode correctly (mingw32)

Follow-up Comment #5, bug #47701 (project wget): In order for you to see the files with non-ASCII names correctly named on your Windows disk, all the non-ASCII characters in the file names must be supported by the current system codepage. In addition, your wget must be built with libiconv. If

[Bug-wget] [bug #47701] wget 1.17.1 fails to convert from percent encoding to unicode correctly (mingw32)

Follow-up Comment #1, bug #47701 (project wget): You need to give Wget the --local-encoding=UTF-8 command-line option, because the URL you are trying to fetch is actually in UTF-8 encoding (and then each byte of the UTF-8 sequence is encoded with percent escapes on top of that). When I use that

[Bug-wget] [bug #47689] Support for UTF-16 encoding.

Follow-up Comment #1, bug #47689 (project wget): This site does work for me with Wget 1.16.1 on MS-Windows, with the exact command you have shown. The file index.html is downloaded and it is encoded in UTF-16LE on my disk. So I'm unsure why it doesn't work for you.

Re: [Bug-wget] HAVE_CARES on Windows

> From: Gisle Vanem > Date: Mon, 11 Apr 2016 11:30:45 +0200 > > Tim Rühsen wrote: > > > As Eli, I would like to know a few more details. > > Is it possible to make c-ares return the 'native' socket numbers to not get > > in > > conflict with gnulib ? > > As Eli pointed out,

Re: [Bug-wget] HAVE_CARES on Windows

> From: Tim Rühsen > Date: Sun, 10 Apr 2016 20:29:36 +0200 > > > I have tried building latest Wget with '-DHAVE_LIBCARES' > > and all resolve attempts failed due to Gnulib's select() > > is not compatible with the socket-number(s) returned from > > a normal C-ares library on

Re: [Bug-wget] HAVE_CARES on Windows

> From: Gisle Vanem > Date: Sat, 9 Apr 2016 21:58:18 +0200 > > I have tried building latest Wget with '-DHAVE_LIBCARES' > and all resolve attempts failed due to Gnulib's select() > is not compatible with the socket-number(s) returned from > a normal C-ares library on Windows.

Re: [Bug-wget] --no-check-certificate does not work in 1.11.4.3287

> From: Tim Paulson > Date: Fri, 19 Feb 2016 16:32:21 + > > The following command with -no-check-certificate works in wget 1.10.2 but > fails in 1.11.4 on Win7. > wget -t 3 --http-user=admin --http-passwd=password --no-check-certificate >

Re: [Bug-wget] [Patch] Use -isystem in Makefile to suppress warnings from libraries

> From: Darshit Shah > Date: Fri, 29 Jan 2016 15:18:57 +0100 > > A recent GCC / LLVM update has caused my setup to spew far too many > warnings on compiling Wget. On a closer look, they all come from > Gnulib code. I propose the attached patch to explicitly mark those > files

Re: [Bug-wget] [Patch] Use -isystem in Makefile to suppress warnings from libraries

> From: Darshit Shah > Date: Fri, 29 Jan 2016 15:45:02 +0100 > Cc: Bug-Wget > > Most of them are actually false positives, probably due to us. Gnulib > uses some more modern code extensions and the compiler keeps warning > us about it since we set the C

[Bug-wget] [bug #46943] Crash on old CPU w/o SSE2

Follow-up Comment #2, bug #46943 (project wget): Did you build wget yourself, or did you download its binary from somewhere? If you downloaded a precompiled binary, can you tell which site did you download it from? ___ Reply to this item

Re: [Bug-wget] Support non-ASCII URLs

> From: Giuseppe Scrivano <gscriv...@gnu.org> > Cc: tim.rueh...@gmx.de, bug-wget@gnu.org > Date: Tue, 12 Jan 2016 20:58:16 +0100 > > Eli Zaretskii <e...@gnu.org> writes: > > > This was fixed by Tim in the meantime. Are you running the current > > Git v

Re: [Bug-wget] Support non-ASCII URLs

> From: Giuseppe Scrivano > Cc: Tim Rühsen , bug-wget@gnu.org > Date: Tue, 12 Jan 2016 12:19:06 +0100 > > >> FAIL: Test-iri-forced-remote > >> > >> My son has birthday tomorrow, so I am not sure how much time I can spend > >> on > >> the weekend on this

Re: [Bug-wget] Support non-ASCII URLs

> From: Tim Rühsen > Date: Sun, 20 Dec 2015 21:34:18 +0100 > > Please review this patch. Looks good to me, thanks.

Re: [Bug-wget] Support non-ASCII URLs

> From: Tim Rühsen <tim.rueh...@gmx.de> > Cc: Giuseppe Scrivano <gscriv...@gnu.org>, Eli Zaretskii <e...@gnu.org> > Date: Fri, 18 Dec 2015 22:41:29 +0100 > > 1. Maybe do_conversion() should take a char * argument instead of const char > *. We avoid one

Re: [Bug-wget] Support non-ASCII URLs

> Date: Sat, 19 Dec 2015 10:15:03 +0200 > From: Eli Zaretskii <e...@gnu.org> > Cc: bug-wget@gnu.org > > > 2. contrib/check-hard fails with > > TESTS_ENVIRONMENT="LC_ALL=tr_TR.utf8 VALGRIND_TESTS=0" make check > > > > FAIL: Test-iri-forced-r

Re: [Bug-wget] Support non-ASCII URLs

> From: Giuseppe Scrivano <gscriv...@gnu.org> > Cc: bug-wget@gnu.org, Eli Zaretskii <e...@gnu.org> > Date: Fri, 18 Dec 2015 11:31:17 +0100 > > >> Attached. > > > > Nice, thank you. > > > > There is just one test not passing: Test-ftp-iri.p

Re: [Bug-wget] Support non-ASCII URLs

nd create the attachment/patch > with 'git format -1' (or -2 for the latest two commits). That makes it easier > for us to apply the patch since author (you) and commit message are copied as > well. Attached. >From 197483b6c62dcea1a900d626c79ba7e65a0c1e67 Mon Sep 17 00:00:00 2001 From: Eli

Re: [Bug-wget] Support non-ASCII URLs

> From: Tim Rühsen > Cc: gscriv...@gnu.org > Date: Thu, 17 Dec 2015 21:16:28 +0100 > > There is just one test not passing: Test-ftp-iri.px > > Maybe the test is wrong (using --local-encoding=iso-8859-1, but writing to an > UTF-8 filename). I am not very much into FTP. How

Re: [Bug-wget] Marking Release v1.17.1?

meant a commit log message formatted according to ChangeLog rules.) >From 9a0c637b07be7b842b9be21488238d578f39d781 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii <e...@gnu.org> Date: Wed, 16 Dec 2015 14:40:17 +0200 Subject: [PATCH] Avoid hanging on MS-Windows when invoked with --connect-t

Re: [Bug-wget] Support non-ASCII URLs

> From: Giuseppe Scrivano > Cc: bug-wget@gnu.org, andries.brou...@cwi.nl > Date: Wed, 16 Dec 2015 10:53:51 +0100 > > > + for (;;) > > + { > > + if (iconv (cd, , , , ) != (size_t)(-1)) > > + { > > + /* Flush the last bytes. */ > > + iconv (cd,

Re: [Bug-wget] Support non-ASCII URLs (Was: GNU wget 1.17.1 released)

> Date: Sun, 13 Dec 2015 20:04:31 +0100 > From: "Andries E. Brouwer" <andries.brou...@cwi.nl> > Cc: "Andries E. Brouwer" <andries.brou...@cwi.nl>, bug-wget@gnu.org > > On Sun, Dec 13, 2015 at 08:01:27PM +0200, Eli Zaretskii wrote: > > > If

Re: [Bug-wget] URL encoding issues (Was: GNU wget 1.17.1 released)

> From: Tim Ruehsen <tim.rueh...@gmx.de> > Cc: Eli Zaretskii <e...@gnu.org> > Date: Tue, 15 Dec 2015 11:02:21 +0100 > > I pushed a conversion fix to master. Thanks! > There is another bug in wget that comes out with > wget -d --local-encoding=cp1255 > 'http

Re: [Bug-wget] Support non-ASCII URLs

This second part is the main part of the change. It uses 'iconv', when available, to convert the file names to the local encoding, before saving the files. Note that the same function I modified is used by ftp.c, so downloading via FTP should also work with non-ASCII file names now; however, I

Re: [Bug-wget] URL encoding issues (Was: GNU wget 1.17.1 released)

> From: Tim Rühsen > Date: Mon, 14 Dec 2015 20:22:41 +0100 > > > 1. The functions that call 'iconv' (in iri.c) don't make a point of > > flushing the last portion of the converted URL after 'iconv' > > returns successfully having converted the input string in its > >

Re: [Bug-wget] GNU wget 1.17.1 released

> From: Tim Rühsen > Date: Sun, 13 Dec 2015 15:17:02 +0100 > Cc: andries.brou...@cwi.nl > > Andries, thanks for insisting. > > As Andries says, I came up with a polished version of his patch (17th > August), > but got no review resp. 'ok for pushing'. AFAICS, the patch

Re: [Bug-wget] Marking Release v1.17.1?

> From: Gisle Vanem > Date: Sat, 12 Dec 2015 13:58:07 +0100 > > > Here's another one that I thought was already fixed, but apparently > > wasn't - --connect-timeout doesn't work on Windows without this patch > > You're right. This is needed: > > --- src/connect.c~0

Re: [Bug-wget] GNU wget 1.17.1 released

> From: Tim Rühsen > Cc: andries.brou...@cwi.nl > Date: Sun, 13 Dec 2015 17:49:46 +0100 > > Someone has to implement/code it in a backward compatible fashion. > We have coded this (or similar) already in the 'wget2' branch - which is > absolutely not mergable with master. I

Re: [Bug-wget] GNU wget 1.17.1 released

> Date: Sun, 13 Dec 2015 18:35:30 +0100 > From: "Andries E. Brouwer" <andries.brou...@cwi.nl> > Cc: bug-wget@gnu.org, Eli Zaretskii <e...@gnu.org>, andries.brou...@cwi.nl > > The current state of affairs as I see it: > > 1. wget is seriously bro

Re: [Bug-wget] Windows cert store support

> Date: Thu, 10 Dec 2015 01:12:37 +0100 > From: Ángel González > Cc: bug-wget > > On 09/12/15 03:06, Random Coder wrote: > > I'm not sure if the wget maintainers would be interested, but I've > > been carrying this patch around in my private builds of wget

Re: [Bug-wget] bad filenames (again)

Date: Sun, 23 Aug 2015 17:16:37 +0200 From: Ángel González keis...@gmail.com CC: bug-wget@gnu.org On 23/08/15 16:47, Eli Zaretskii wrote: Wrong. I can work with a larger one by using a UNC path. But then you will be unable to use relative file names, and will have to convert all

Re: [Bug-wget] bad filenames (again)

Date: Sun, 23 Aug 2015 16:15:04 +0200 From: Ángel González keis...@gmail.com CC: bug-wget@gnu.org On 20/08/15 04:42, Eli Zaretskii wrote: From: Ángel González wrote: On 19/08/15 16:38, Eli Zaretskii wrote: Indeed. Actually, there's no need to allocate memory dynamically, neither

Re: [Bug-wget] bad filenames (again)

From: Tim Ruehsen tim.rueh...@gmx.de Cc: Andries E. Brouwer andries.brou...@cwi.nl Date: Thu, 20 Aug 2015 10:47:35 +0200 Tim says he has some/most of that coded on a branch, so I think we should start by merging that branch, and then take it from there. It is in branch 'tim/wget2'.

Re: [Bug-wget] bad filenames (again)

Date: Wed, 19 Aug 2015 02:52:57 +0200 From: Andries E. Brouwer andries.brou...@cwi.nl Cc: bug-wget@gnu.org Look at the remote filename. Assign a character set as follows: - if the user specified a from-charset, use that - if the name is printable ASCII (in 0x20-0x7f), take ASCII - if

Re: [Bug-wget] bad filenames (again)

Date: Tue, 18 Aug 2015 22:28:21 +0200 From: Andries E. Brouwer andries.brou...@cwi.nl Cc: Andries E. Brouwer andries.brou...@cwi.nl, tim.rueh...@gmx.de, bug-wget@gnu.org What is needed to have a full Unicode support in wget on Windows is to provide replacements for all the

Re: [Bug-wget] bad filenames (again)

Date: Wed, 19 Aug 2015 01:43:51 +0200 From: Ángel González keis...@gmail.com +int +wc_utime (unsigned char *filename, struct _utimbuf *times) +{ + wchar_t *w_filename; + int buffer_size; + + buffer_size = sizeof (wchar_t) * MultiByteToWideChar(65001, 0,

Re: [Bug-wget] bad filenames (again)

Date: Wed, 19 Aug 2015 20:50:55 +0200 From: Andries E. Brouwer andries.brou...@cwi.nl Cc: Andries E. Brouwer andries.brou...@cwi.nl, keis...@gmail.com, bug-wget@gnu.org On Wed, Aug 19, 2015 at 09:46:04PM +0300, Eli Zaretskii wrote: OK, but how is this different from what we'd

  1   2   >