[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] --progress=dot:giga

From: Tim Rühsen
Subject: Re: [Bug-wget] --progress=dot:giga
Date: Sun, 16 Jun 2019 11:43:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0

Hi Greg,

I currently can't see that any of us maintainers or contributors will
ever work on this. There is just too much other things to do.

To have a chance, you should add as much details to
as possible.
*IF* you could code an example outside wget, in any language you like,
that would be a great helper. Wget2 has plugin support and we can extend
it to support progress bar implementations - basically in any language.
(Adding command line options via plugin is already functional.)

If this is really an important issue for you, go ahead and be the
driving force behind it. We give you all the help that our time allows.

Regards, Tim

On 15.06.19 18:55, Greg Knittl wrote:
> Hi Tim,
> I would find another column for the wall clock absolute estimated
> completion time useful as I often try to calculate this in my head.
> I think I only care about the dots because they show that the download
> is proceeding normally. Wget already outputs a message if it retries. If
> there is a situation where the download is hanging but wget is not
> restarting it then I think I would prefer a message instead of trying to
> guess what is happening from dots not appearing. With sufficient
> messages in place it would be possible to skip the dots entirely. Or
> instead of dots output a brief message to give download status.
> Whether there are dots or not, let the user select a time or per cent
> complete interval for status updates. I typically pipe wget progress
> output to a file. Usually I don't look at the output at all. In most
> cases it would be sufficient if wget output an initial row after say 1%
> complete and then I could signal wget if I want it to output another
> progress line.
> If wget must have dots then instead of mega and giga options, perhaps
> let the user set the dot size and calibrate the left column units around
> that. If wget allowed per cent complete or time intervals that would set
> the dot size, although not likely to a round number.
> Personally I'm fine with 32 dots per line. I find blocks of 8 easier to
> read (which I usually don't) than blocks of 10. But if anyone cares and
> has time to code it, perhaps an option to specify the dot cluster size
> and clusters per line.
> thanks,
> Greg
> On 2019-06-12 2:58 p.m., Tim Rühsen wrote:
>> Hi Greg,
>> looking at it when downloading a large file, I have to agree.
>> A dynamic multiplier on the left would be nice (K->M->G).
>> I added this as a comment to https://gitlab.com/gnuwget/wget2/issues/342.
>> Thanks for the feedback.
>> Regards, Tim
>> On 12.06.19 06:19, Greg Knittl wrote:
>>> Hi,
>>> --progress=dot:giga on wget 1.17.1 outputs 32 dots per line where each
>>> dot represents 1MB downloaded.
>>> The cumulative total at the left of each line is in KB. I would find MB
>>> easier to understand. It matches up with the dots and better matches the
>>> scale of GigaByte files. I still often have download speeds measured in
>>> KB/sec but I don't recall ever comparing download speed to the
>>> cumulative total on the the left.
>>> I would ask that you at least consider this for wget2. I personally
>>> don't have any programs that read this column of wget output so I would
>>> be fine if it changes in the current wget1 but I would understand if you
>>> consider it an API that you don't want to break.
>>> thanks,
>>> Greg

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]