Re: [Bug-wget] Support file: scheme

> "TR" == Tim Rühsen writes: TR> Wget is not supposed to support file://. Yes, I am just saying if it did it would make testing easier. If something doesn't work, if it also doesn't even work with just file:///, then one would know it wasn't a network problem, etc.

Re: [Bug-wget] Support file: scheme

rsync too. In fact I can't think of one other remote copying / network downloader that doesn't also work just the same if given both a local origin and destination.

Re: [Bug-wget] Support file: scheme

Just like one can use $ scp fileA fileB with no network needed.

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

> Just try it out and report back if there is a problem. It is hard to reproduce the problem. -- Regards, Peng

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On 18.05.19 13:39, Peng Yu wrote: > On 5/18/19, Tim Rühsen wrote: >> On 17.05.19 23:09, Peng Yu wrote: >>> Hi, >>> >>> curl has this problem "(18) transfer closed with outstanding read data >>> remaining". Does wget have a similar problem like this? Thanks. >>> >>> https://curl.haxx.se/mail/archiv

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On 18.05.19 16:22, Daniel Stenberg wrote: > On Sat, 18 May 2019, Tim Rühsen wrote: > >> The connection is closed prematurely and you do not want to >> re-download everything. >> >> Wget has -c / --continue for that. > > I could be noted that transfers with chunked encoding are rarely resumable. >

[Bug-wget] informations about patch

Hello, is there any news about our patch for the bug (#54769 (https://savannah.gnu.org/bugs/?54769)) ? Adham EL KARN Envoyé à partir de Outlook

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On Sat, 18 May 2019, Tim Rühsen wrote: The connection is closed prematurely and you do not want to re-download everything. Wget has -c / --continue for that. I could be noted that transfers with chunked encoding are rarely resumable. -- / daniel.haxx.se

[Bug-wget] How to print just download time to stderr along with a tag when the output is to stdout?

Hi, When I use wget to download and output to stdout, I want to print a tag (any string that a user can specify in the command line) and the download time (separated by a TAB) to stderr. Is this possible with wget? Thanks. -- Regards, Peng

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On 5/18/19, Tim Rühsen wrote: > On 17.05.19 23:09, Peng Yu wrote: >> Hi, >> >> curl has this problem "(18) transfer closed with outstanding read data >> remaining". Does wget have a similar problem like this? Thanks. >> >> https://curl.haxx.se/mail/archive-2018-10/0015.html > > The connection is c

Re: [Bug-wget] Fwd: Fwd: Re: RESEND1: wget-1.20-win32

WQ wrote: *Also :* https://saimei.ftp.acc.umu.se/mirror/ipfire.org/releases/ipfire-2.x/2.23-core131/ipfire-2.23.x86_64-full-core131.iso I see no scroll-problem with this file. My console width is 140 character. But I see the filename is truncated by 1 character; '.iso' -> '.is': ipfire-2.23.

Re: [Bug-wget] Does wget has the "outstanding read data" problem?

On 17.05.19 23:09, Peng Yu wrote: > Hi, > > curl has this problem "(18) transfer closed with outstanding read data > remaining". Does wget have a similar problem like this? Thanks. > > https://curl.haxx.se/mail/archive-2018-10/0015.html The connection is closed prematurely and you do not want to

Re: [Bug-wget] Support file: scheme

On 17.05.19 07:37, 積丹尼 Dan Jacobson wrote: > I can do > $ curl file:///dev/null > > If I could do the same with wget, then I could e.g., see the effects of > adding --quiet vs. not adding it, without needing a HTTP server. > Wget is not supposed to support file://. You can easily use 'cp' or 'c

Re: [Bug-wget] RESEND1: wget-1.20-win32

On 18.05.19 11:33, Darshit Shah wrote: > Thanks! > > I'll try and see if I can reproduce this for a test. > > * Jernej Simončič [190513 09:27]: >> On Sunday, May 12, 2019, 17:45:31, Darshit Shah wrote: >> >>> Could you please let us know which sites? >> >> It happens everywhere, as long as the f

Re: [Bug-wget] Fwd: Fwd: Re: RESEND1: wget-1.20-win32

Hi, yes, I get the point. You've sent a couple of examples, please do not keep sending single links in emails. As Jernej mentioned, this seems to happen in all cases where the filename is too long. There seems to be a patch, I will look into it. Once again, as I have stated in the past, this is

Re: [Bug-wget] RESEND1: wget-1.20-win32

Thanks! I'll try and see if I can reproduce this for a test. * Jernej Simončič [190513 09:27]: > On Sunday, May 12, 2019, 17:45:31, Darshit Shah wrote: > > > Could you please let us know which sites? > > It happens everywhere, as long as the filename is long enough to > require scrolling. I re

[Bug-wget] Fwd: Fwd: Re: RESEND1: wget-1.20-win32

*Also :* https://fpdownload.macromedia.com/pub/flashplayer/latest/help/install_flash_player.exe Forwarded Message Subject:Fwd: Re: [Bug-wget] RESEND1: wget-1.20-win32 Date: Thu, 16 May 2019 14:31:49 +0200 From: WQ To: bug-wget@gnu.org *Also :* https://saim