Re: [Bug-wget] --progress should not be overridden by --quiet

[Darshit Shah]

Sending to bug-wget.

On Thu, May 1, 2014 at 4:24 PM, Darshit Shah <address@hidden> wrote:
> On Thu, May 1, 2014 at 3:58 PM, Gisle Vanem <address@hidden> wrote:
>> You wrote:
>>
>>> I honestly haven't looked at the Windows specific part of the codebase
>>> at all, so I don't know how mswindows.c works. I'll however give it a
>>> look when I can.
>>
>>
>> Hi again.
>>
>> I built Wget today from savannah with the updated progress patches.
>> But this new '--show-progress' (or something else?) is a bit broken here on
>> MingW. The 1st character on line >1 are missing. E.g:
>>
>> wget.exe  -q --show-progress -rApng ftp://ftp.watt-32.net/watt-doc/
>>
>> ftp.watt-32.net/watt-doc/.listing     [   <=>                   ] 56,013
>> 116KB/s   in 0.5s
>> tp.watt-32.net/watt-doc/doxygen.p 100%[========================>] 1,576
>> --.-K/s   in 0.003s
>> tp.watt-32.net/watt-doc/ftv2blank 100%[========================>] 174
>> --.-K/s   in 0s
>> tp.watt-32.net/watt-doc/ftv2doc.p 100%[========================>] 255
>> --.-K/s   in 0s
>> tp.watt-32.net/watt-doc/ftv2folde 100%[========================>] 259
>> --.-K/s   in 0s
>> tp.watt-32.net/watt-doc/ftv2folde 100%[========================>] 261
>> --.-K/s   in 0s
>>
>> ---------
> Oh I want to say, "It's not a bug, it's a feature."
> The files you're trying to download have names longer than the maximum
> allowed. So, wget cycles through the characters like a ticker. But
> since your files are small, they download before wget can actually
> tick.
>
> Although I do think the ticker isn't being reset after each file, and
> hence you see the first character missing. Maybe it should be reset.
> I'll look into it.
>
> Also, I don't like how the output is often staggered in this use case.
> I'd like to create more fixed bounds for each column. I'll try working
> on that when I can. Suggestions/patches are more than welcome.
>>
>> The progress is even more broken with 'dot's:
>>  wget.exe  -q --show-progress --progress=dot -rApng
>> ftp://ftp.watt-32.net/watt-doc/
>>
>>     0K .......... .......... .......... .......... ..........  105K
>>    50K ....                                                   2.90M=0.5s
>>
>>
>>     0K .                                                     100%
>> 878K=0.002s
>>
>>
>>     0K                                                       100% 2.51M=0s
>>
>>
>>     0K                                                       100% 3.60M=0s
>>
>>
>>     0K                                                       100% 3.76M=0s
>>
>>
>>     0K                                                       100% 3.89M=0s
>>
>>
>>     0K                                                       100% 3.30M=0s
>>
>> ------------
>>
>> (3 empty lines for each file).
>>
> I'm not sure. I didn't touch the implementation of the dot progress
> bar. When I tried it with a large file, it seemed fine. Maybe I should
> have run my tests with a bunch of small files too. This, IMHO, is only
> a formatting problem. The file is downloaded much before Wget gets a
> chance to print all the dots.
>
> The excessive blank lines are my fault. I cleared those from the bar
> progress, but forgot to do the same from the dots style too.
> Those lines are printed to format the original verbose output, but
> instead only the blank lines get printed in the quiet version. I'll
> fix that.
>
> I can confirm that this indeed is the case because I ran wget compiled
> against v1.15 and compared the output. The individual progress bars
> pretty much line up exactly.
>
>> Besides, the Windows title-bar is missing with '-q --show-progress' now. I
>> don't
>> think that was the idea. The reason is that:
>>  #ifdef WINDOWS
>>          ws_changetitle (hurl);
>>  #endif
>>
>> is called only if 'opt.verbose' is true. IMHO the line:
>> char *hurl = url_string (u, URL_AUTH_HIDE_PASSWD);
>>
>> should set a global WINDOWS-only string/buffer just for these cases. Hence
>> no need to call ws_changetitle(hurl). Just let ws_percenttitle() use this
>> global string. How about it?
>>
> I'm not a fan of global strings/buffers and would like to avoid adding
> new ones. However, looking at the code, your approach seems like the
> cleanest. Does anyone else have better ideas??
>
> Also, I'd request you to make the changes and submit a patch for two
> major reasons:
> 1. I'm not very thorough with the Windows-specific code and don't know
> about what calls what from where.
> 2. I don't have a Windows machine on hand for testing and I'm afraid
> of breaking things without.
>
> To add to it all, I'm keeping a little too busy these days with my
> academic work too.

Please do check the attached patch. It should fix the erroneous empty
lines you reported.

-- 
Thanking You,
Darshit Shah

0001-Fix-extra-newlines-when-not-in-verbose-mode.patch
Description: Text Data