Re: [Bug-wget] limit download size -- 201901233

On Thu, 24 Jan 2019 at 12:11, wrote: > > - Yousong Zhou wrote : > > On Thu, 24 Jan 2019 at 02:32, Tim Rühsen wrote: > > > > > > On 23.01.19 03:47, c...@free.fr wrote: > > > > Hi, > > > > acording to > > > > $wget --he

Re: [Bug-wget] limit download size -- 201901233

On Thu, 24 Jan 2019 at 02:32, Tim Rühsen wrote: > > On 23.01.19 03:47, c...@free.fr wrote: > > Hi, > > acording to > > $wget --help > > i should send reports and suggestions to this address, so i hope i'm > > doing right here. > > > >the version of my distribution, given by the above

Re: [Bug-wget] limit download size -- 201901233

On Wed, 23 Jan 2019 at 12:06, wrote: > > Hi, > acording to > $wget --help > i should send reports and suggestions to this address, so i hope i'm doing > right here. > >the version of my distribution, given by the above command, is "GNU Wget > 1.18" > >and i don't seem to see an

[Bug-wget] [bug #50260] Link failed caused by bad linker option -R

Follow-up Comment #7, bug #50260 (project wget): Yes, using LIB instead of LTLIB worked. And indeed, according to the gnulib manual, the LTLIB was intended for linking with libtool. https://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html

[Bug-wget] [bug #50260] Link failed caused by bad linker option -R

Follow-up Comment #5, bug #50260 (project wget): Digging further, this was probably caused by the commit adding LTLIBICONV to LDADD for wget commit d4f97dc9afd149afe1f7b16a84eebb4bab1f044a Author: Tim Rühsen Date: Sat Jun 11 22:38:42 2016 +0200 Add libraries to LDADD

[Bug-wget] [bug #50260] Link failed caused by bad linker option -R

Follow-up Comment #4, bug #50260 (project wget): The error happened with wget-1.19 vanilla tarball. The -R option was probably from m4/lib-link.m4 (search for "-R$found_dir" in that file) and according from the comment there, it was intended for libtool. That macro in m4/lib-link.m4 was

[Bug-wget] [bug #50260] Link failed caused by bad linker option -R

Follow-up Comment #2, bug #50260 (project wget): Patching configure.ac to use libtool with AC_PROG_LIBTOOL fixed the link issue for me, though I had to also patch the m4/po.m4 file to workaround the gettext version check. The patch hunks are available at

[Bug-wget] [bug #50260] Link failed caused by bad linker option -R

Follow-up Comment #1, bug #50260 (project wget): Sorry, 1.17.1 was intended as a comparison instead of 1.18. ___ Reply to this item at: ___ Message

[Bug-wget] [bug #50260] Link failed caused by bad linker option -R

URL: Summary: Link failed caused by bad linker option -R Project: GNU Wget Submitted by: yousong Submitted on: Thu 09 Feb 2017 03:14:16 AM UTC Category: Build/Install

Re: [Bug-wget] Multi segment download

On 9 September 2015 at 11:20, Hubert Tarasiuk wrote: > On Sat, Aug 29, 2015 at 12:50 AM, Darshit Shah wrote: >> Thanking You, >> Darshit Shah >> Sent from mobile device. Please excuse my brevity >> On 29-Aug-2015 1:13 pm, "Tim Rühsen"

Re: [Bug-wget] Multi segment download

On 29 August 2015 at 04:04, Abhilash Mhaisne wrote: > Hey all. I am new to this mailing list. > As far as I've used wget, it downloads a specified file as a single segment. > Can we modify this such that wget will download a file by dividing it into > multiple >

Re: [Bug-wget] Issue with --content-on-error and --convert-links

Hi Alexander, On Apr 5, 2015 3:57 AM, Alexander Kurakin kuraga...@mail.ru wrote: Good day! So when the patch can be applied? It has been in the git repository for a while shortly after the release of v1.16.3 (not yet in a release version). cheers, yousong

Re: [Bug-wget] Issue with --content-on-error and --convert-links

Hi, On 31 January 2015 at 10:13, Yousong Zhou yszhou4t...@gmail.com wrote: Ah sorry, my fault / misunderstanding. Since the patch changes Wget behaviour I would apply it after the next bugfix release. A test case would be perfect. Please consider creating a python test case (see

Re: [Bug-wget] Issue with --content-on-error and --convert-links

On 31 January 2015 at 07:53, Giuseppe Scrivano gscriv...@gnu.org wrote: Yousong Zhou yszhou4t...@gmail.com writes: On 29 January 2015 at 21:26, Tim Ruehsen tim.rueh...@gmx.de wrote: Hi Yousong, this patch seems to be incomplete. Do you have a complete patch (e.g. +new option, + docs

Re: [Bug-wget] Issue with --content-on-error and --convert-links

On 29 January 2015 at 21:26, Tim Ruehsen tim.rueh...@gmx.de wrote: Hi Yousong, this patch seems to be incomplete. Do you have a complete patch (e.g. +new option, + docs) or are you going to work on it ? That patch was only intended as a ephemeral one to see if it can solve the issue

Re: [Bug-wget] Issue with --content-on-error and --convert-links

for this and the current doc is just fine. But I will try adding an test cases for this. Regards yousong Tim On Thursday 16 October 2014 15:24:48 Yousong Zhou wrote: On 13 October 2014 10:25, Joe Hoyle joeho...@gmail.com wrote: Hi All, I’m having issues using --convert

Re: [Bug-wget] Need wget feature defending against evil ISP's HPPT 302 HIJACK

On 24 December 2014 at 16:48, Dawei Tong sec...@yahoo.com wrote: Hell wget developers:I live in China and has an China TieTong Telecommunications DSL connetion .This ISP 's servers continous sending http 302 redirect with junk/AD link that corrupt my downloading files. I found this by

Re: [Bug-wget] Need wget feature defending against evil ISP's HPPT 302 HIJACK

On 26 December 2014 at 11:40, Yousong Zhou yszhou4t...@gmail.com wrote: Here is my test result:cmp -b -l b1_WoT.0.9.4_cn_setup.944980-2.bin b2_WoT.0.9.4_cn_setup.944980-2.bin 456582373 261 M-1 110 H 456582374 44 $124 T It's binary data. I suspect your ISP has inserted any HTML

Re: [Bug-wget] [PATCH] Small fix for limited number of strings (and potential garbage value) in arguments to concat_strings

On 21 October 2014 16:17, Pär Karlsson feino...@gmail.com wrote: Yes, you are right, of course. Looking through the original implementation again, it seems water tight. clang probably complains about the uninitialized values above argcount in saved_lengths[], that are never reached. The

Re: [Bug-wget] [PATCH] Small fix for limited number of strings (and potential garbage value) in arguments to concat_strings

Hi, Pär. I got a few comments inline. On 21 October 2014 05:47, Pär Karlsson feino...@gmail.com wrote: Whoops, I realised I failed on the GNU coding standards, please disregard the last one; the patch below should be better. My apologies :-/ /Pär diff --git a/src/ChangeLog

Re: [Bug-wget] [PATCH] Small fix for limited number of strings (and potential garbage value) in arguments to concat_strings

On 21 October 2014 10:02, Yousong Zhou yszhou4t...@gmail.com wrote: Hi, Pär. I got a few comments inline. On 21 October 2014 05:47, Pär Karlsson feino...@gmail.com wrote: Whoops, I realised I failed on the GNU coding standards, please disregard the last one; the patch below should be better

Re: [Bug-wget] [PATCH] Small fix for limited number of strings (and potential garbage value) in arguments to concat_strings

Hi, Pär On 17 October 2014 03:50, Pär Karlsson feino...@gmail.com wrote: Hi, I fould a potential gotcha when playing with clang's code analysis tool. The concat_strings function silently stopped counting string lengths when given more than 5 arguments. clang warned about potential garbage

Re: [Bug-wget] wget

Hi, Bryan Am 18.10.2014 21:43 schrieb Bryan Baas bb...@weycogroup.com: Hi, I was wondering about the command output of wget. I used a Java Runtime exec and, although the wget process ended with a 0 completion code, the results appeared in the error stream and not the output stream. As a

Re: [Bug-wget] Issue with --content-on-error and --convert-links

On 13 October 2014 10:25, Joe Hoyle joeho...@gmail.com wrote: Hi All, I’m having issues using --convert-links” in conjunction with --content-on-error”. Though --content-on-error” is forcing wget to download the pages, the links to that “errored” page is not update in other pages that

Re: [Bug-wget] wget-bug

On Sep 13, 2014 9:39 PM, Nyilas MISY dr.dab...@gmail.com wrote: hello :-) shortly (this is just an example!!) :: [user@host ~]$ wget -r -c -P ~/Downloads/ http://multicommander.com/files/updates/MultiCommander_win32_(4.5.1.1769).exe when the filename(s) contains ( ), then the wget doesn't

Re: [Bug-wget] wget-bug

part and it should work. [user@host ~]$ 2014-09-13 16:04 GMT+02:00 Yousong Zhou yszhou4t...@gmail.com: On Sep 13, 2014 9:39 PM, Nyilas MISY dr.dab...@gmail.com wrote: hello :-) shortly (this is just an example!!) :: [user@host ~]$ wget -r -c -P ~/Downloads/ http

Re: [Bug-wget] Wget export URL list

On 3 September 2014 22:26, Adrian - adrianTNT.com adrian...@adriantnt.com wrote: Hello. Can anyone tell me how to do this with wget ? I want it to spider a given website and return the list of full urls in that website. Any ideas? This can be done by - grepping through stderr output of

Re: [Bug-wget] grab complete download link

Hi, On 21 July 2014 09:38, bas smit baspys...@gmail.com wrote: Dear Darshit Shah Thanks for your response. I tried with the following command: subprocess.call([wget,'--user',user,'--password',passw,'-P',download_dir,'--page-requisites',url,'-o',logfile,\ '--no-check-certificate']) The

Re: [Bug-wget] [PATCH] wget hangs on HTTP 204

On 22 April 2014 21:02, Tim Ruehsen tim.rueh...@gmx.de wrote: Attached is a patch including a new test case. Guiseppe, I made it for a clone of Darshit's clone of Wget. Not sure if it fits into master. Hi, Giuseppe. Just noticed that my previous test cases for --start-pos were not recorded

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

On 5 April 2014 17:28, Jure Grabnar grabna...@gmail.com wrote: Hi, That's true. type is currently only used to filter out types which Wget doesn't support. Do you think parsing it (type) is irrelevant? IMHO, if it will not be used in the near future, then better document or remove

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

of wget. yousong This was the main purpose of the 1st patch. On 1 April 2014 03:20, Yousong Zhou yszhou4t...@gmail.com wrote: Hi, Jure. On 1 April 2014 03:46, Jure Grabnar grabna...@gmail.com wrote: Hello, thanks for your feedback! I corrected the first patch

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

Hi, On 1 April 2014 23:02, Jure Grabnar grabna...@gmail.com wrote: On 1 April 2014 10:39, Yousong Zhou yszhou4t...@gmail.com wrote: On 1 April 2014 15:48, Jure Grabnar grabna...@gmail.com wrote: Hi, I debugged code before writing the 1st patch and found out that if type attribute

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

Hi, Jure. On 1 April 2014 03:46, Jure Grabnar grabna...@gmail.com wrote: Hello, thanks for your feedback! I corrected the first patch. Then the 1st one is fine with me. I am not fluent with Metalink and libmetalink on how it handles the type attribute. In version 4.0 of the standard, there

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

Hi, On 28 March 2014 20:33, Jure Grabnar grabna...@gmail.com wrote: Hi, Thank you Yousong. I've listened to your advice and changed type of resource-type to enum url_scheme. Now it looks much cleaner. Using enum is a step forward. @@ -134,7 +135,20 @@ parse_metalink(char *input_file)

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

Hi, Jure. On 22 March 2014 18:02, Jure Grabnar grabna...@gmail.com wrote: Hi, thank you for your feedback, Darshit, Yousong! I reverted magic number back to its original state ('tmp2'), because it should be there (I overlooked that 'tmp' variable is changed in the very next statement).

Re: [Bug-wget] Fwd: [GSoC] Extend concurrency support in Wget

Hi, Jure. On 21 March 2014 03:23, Jure Grabnar grabna...@gmail.com wrote: Thank you for you feedback Darshit. I changed my proposal according to your advices. Hopefully a new version is better. I'm also sending corrected patches, again thanks to your review, Darshit. First patch allows

Re: [Bug-wget] [PATCH v6 0/5] Make wget capable of starting downloads from a specified position.

On 21 March 2014 19:34, Giuseppe Scrivano gscriv...@gnu.org wrote: I've done some more tests and now pushed! Finally. Thank you, Tim, Darshit, Giuseppe, for your time and attention on this. yousong

[Bug-wget] [PATCH v6 0/5] Make wget capable of starting downloads from a specified position.

of deriving it from existing file which is what --continue currently does. When both this option and --continue are both specified which does not make much sense, wget will warn and proceed as if --continue was not there. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- v5 - v6 - Fix a typo

[Bug-wget] [PATCH v6 4/5] Tests: Add test cases for option --start-pos.

Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- tests/ChangeLog|7 tests/Test--start-pos--continue.px | 57 tests/Test--start-pos.px | 46 + tests/Test-ftp--start-pos.px | 42

[Bug-wget] [PATCH v6 3/5] Tests: exclude existing files from the check of unexpected downloads.

Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- tests/ChangeLog |5 + tests/WgetTest.pm.in |5 - 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/tests/ChangeLog b/tests/ChangeLog index a7db249..d23e76e 100644 --- a/tests/ChangeLog +++ b/tests/ChangeLog

[Bug-wget] [PATCH v6 2/5] Tests: fix TYPE and RETR command handling.

- FTPServer.pm's handling of TYPE command would ignore binary mode transfer request. - The FTP server would run into dead loop sending the same content forever. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- tests/ChangeLog|5 + tests/FTPServer.pm | 12

[Bug-wget] [PATCH v6 1/5] Make wget capable of starting downloads from a specified position.

This patch adds an option `--start-pos' for specifying starting position of a HTTP or FTP download. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- doc/ChangeLog |4 doc/wget.texi | 16 src/ChangeLog |7 +++ src/ftp.c |2 ++ src/http.c|2

Re: [Bug-wget] [GSoC] Refactoring the Test Suite

. I'll try to make my commits smaller next time. Work till now I is not likely to be divided into small commits though ;( And thanks very much for the advice! 2014-03-10 15:38 GMT+08:00 Yousong Zhou yszhou4t...@gmail.com: Hi, Zihang, On 10 March 2014 13:05, 陈子杭 (Zihang

Re: [Bug-wget] [GSoC PATCH 11/11] in conf, rename register to rule and hook

On 14 March 2014 21:28, 陈子杭 (Zihang Chen) chsc4...@gmail.com wrote: So sorry I flooded the mailing list. I thought --chain-reply-to is turned on by default :( I think --no-chain-reply-to is okay. yousong

Re: [Bug-wget] [GSoC] Refactoring the Test Suite

Hi, Zihang, On 10 March 2014 13:05, 陈子杭 (Zihang Chen) chsc4...@gmail.com wrote: Hi, Darshit. I fixed the line ending using git config --global autocrlf input. Line endings should be lf now. I also added some documentation. File modes for Test-*.py are 755 now. I just did a quick check on

Re: [Bug-wget] [GSoC] Refactoring the Test Suite

Hi, Zihang and Darshit, and all. On 9 March 2014 09:39, Darshit Shah dar...@gmail.com wrote: Hi Zihang, I just had a brief glance through the whole commit. That's a very large change! It's essentially the same code with lots of moving around and cosmetic changes. However, I do have a

Re: [Bug-wget] Using GNU Wget 1.13.4 on an https page...

On 5 March 2014 22:33, Pauline_FTP@dmin learningadvoc...@gmail.com wrote: Pauline_FTP@dmin learningadvoc...@gmail.com Feb 27 (6 days ago) Hi, Upon reading the manual regarding the topic above, I realized that I am at a loss of how to begin. The information is so overwhelming that I feel I

Re: [Bug-wget] [bug-wget] Unable to execute the Test Suite

Hi, On Fri, 21 Feb 2014, Darshit Shah wrote: Hi all, I was trying to run the test suite on Wget, but it keeps failing due to the new submodule. At first I thought the issue was probably with the parallel-wget branch, so I switched to master. Yet the same problem. Just as a control test, I

Re: [Bug-wget] wget confused by URL

Hi, On Thu, 20 Feb 2014, James Macomber wrote: Hi, May be my n00bness, but I can't seem to get the syntax right for this command or the command is getting confused by my values. I am using the win86_64 version 1.11.4. I am calling wget -r -i C:\Users\macombej\Desktop\wgeturl.txt -S -o

[Bug-wget] [PATCH v5 0/4] Make wget capable of starting downloads from a specified position.

of deriving it from existing file which is what --continue currently does. When both this option and --continue are both specified which does not make much sense, wget will warn and proceed as if --continue was not there. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- v4 - v5 - Reworked

[Bug-wget] [PATCH v5 1/4] Make wget capable of starting downloads from a specified position.

This patch adds an option `--start-pos' for specifying starting position of a HTTP or FTP download. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- doc/ChangeLog |4 doc/wget.texi | 16 src/ChangeLog |7 +++ src/ftp.c |2 ++ src/http.c|2

[Bug-wget] [PATCH v5 3/4] Tests: exclude existing files from the check of unexpected downloads.

Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- tests/ChangeLog |5 + tests/WgetTest.pm.in |5 - 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/tests/ChangeLog b/tests/ChangeLog index a7db249..d23e76e 100644 --- a/tests/ChangeLog +++ b/tests/ChangeLog

[Bug-wget] [PATCH v5 2/4] Tests: fix TYPE and RETR command handling.

- FTPServer.pm's handling of TYPE command would ignore binary mode transfer request. - The FTP server would run into dead loop sending the same content forever. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- tests/ChangeLog|5 + tests/FTPServer.pm | 12

[Bug-wget] [PATCH v5 2/4] Tests: fix TYPE and RETR command handling.

- FTPServer.pm's handling of TYPE command would ignore binary mode transfer request. - The FTP server would run into dead loop sending the same content forever. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- tests/ChangeLog|5 + tests/FTPServer.pm | 12

Re: [Bug-wget] [PATCH v5 2/4] Tests: fix TYPE and RETR command handling.

Please use this newly sent one of this patch. The old one is incorrect. On 14 February 2014 10:27, Yousong Zhou yszhou4t...@gmail.com wrote: diff --git a/tests/FTPServer.pm b/tests/FTPServer.pm index 2ac72e3..1603caa 100644 --- a/tests/FTPServer.pm +++ b/tests/FTPServer.pm @@ -298,12

[Bug-wget] [PATCH v4] Make wget capable of starting download from a specified position.

On Thursday, February 6, 2014, Tim Ruehsen tim.rueh...@gmx.de wrote: Hi Yousong, please don't forget to send your posts to the mailing list. Sorry for that. On Thursday 06 February 2014 10:27:37 Yousong Zhou wrote: On Wednesday, February 5, 2014, Tim Ruehsen tim.rueh...@gmx.de wrote

Re: [Bug-wget] [PATCH v4] Make wget capable of starting download from a specified position.

Hi, can this feature be picked up? Months have passed and I think a ping will be good. :) yosong On Monday, December 23, 2013, Yousong Zhou yszhou4t...@gmail.com wrote: This patch adds an option `--start-pos' for specifying starting position of a download, both for HTTP

Re: [Bug-wget] Bug report: --content-disposition option disables --continue

On 2 January 2014 07:08, Eternal Sorrow sergam...@inbox.ru wrote: When I set option content-disposition either in command line or in wgetrc, wget refuses to resume download of partially-downloaded file with --continue command line option and strarts download from begining. I tried the

[Bug-wget] [PATCH v3] Make wget capable of starting download from a specified position.

This patch adds an option `--start-pos' for specifying starting position of a download, both for HTTP and FTP. When specified, the newly added option would override `--continue'. Apart from that, no existing code should be affected. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- v2 - v3

Re: [Bug-wget] [PATCH] Make wget capable of starting download from a specified position.

On Sat, Dec 21, 2013 at 11:05:01AM +0100, Dagobert Michelsen wrote: Hi, Am 21.12.2013 um 10:24 schrieb Yousong Zhou yszhou4t...@gmail.com: In my situation, wget was trigger on the remote machine like the following: wget -O - --start-pos $OFFSET $URL | nc -lp 7193 Then on local

[Bug-wget] [PATCH v4] Make wget capable of starting download from a specified position.

This patch adds an option `--start-pos' for specifying starting position of a download, both for HTTP and FTP. When specified, the newly added option would override `--continue'. Apart from that, no existing code should be affected. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- v3 - v4

Re: [Bug-wget] [PATCH] Make wget capable of starting download from a specified position.

On Sat, Dec 21, 2013 at 01:51:04PM +0530, Darshit Shah wrote: I have a few comments on the patch. Commenting inline. Thank you. On Sat, Dec 21, 2013 at 12:32 PM, Yousong Zhou yszhou4t...@gmail.comwrote: This patch adds an option `--start-pos' for specifying starting position

Re: [Bug-wget] [PATCH] Make wget capable of starting download from a specified position.

On Sat, Dec 21, 2013 at 11:05:01AM +0100, Dagobert Michelsen wrote: Hi, Am 21.12.2013 um 10:24 schrieb Yousong Zhou yszhou4t...@gmail.com: In my situation, wget was trigger on the remote machine like the following: wget -O - --start-pos $OFFSET $URL | nc -lp 7193 Then on local

[Bug-wget] [PATCH v2] Make wget capable of starting download from a specified position.

This patch adds an option `--start-pos' for specifying starting position of a download, both for HTTP and FTP. When specified, the newly added option would override `--continue'. Apart from that, no existing code should be affected. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- v1 - v2

[Bug-wget] [PATCH] Make wget capable of starting download from a specified position.

This patch adds an option `--start-pos' for specifying starting position of a download, both for HTTP and FTP. When specified, the newly added option would override `--continue'. Apart from that, no existing code should be affected. Signed-off-by: Yousong Zhou yszhou4t...@gmail.com --- Hi, I