Bug 1068834

Summary: --progress-bar is over-ridden by --quiet
Product: [Fedora] Fedora Reporter: Robert Strickler <bugz.to.anomalyst>
Component: wgetAssignee: Tomáš Hozza <thozza>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 20CC: bugz.to.anomalyst, micah, thozza
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-06 09:55:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert Strickler 2014-02-22 04:16:08 UTC
Description of problem:
when --quiet or --output for log file is specified the progress bar is not dislpayed

Version-Release number of selected component (if applicable):
1.14

How reproducible:
always

Steps to Reproduce:
1.wget --quiet --progress=bar $SRL
2.
3.

Actual results:
no progress is displayed

Expected results:
Progress bar as displayed without --quiet or --ouput

Additional info:
display progress on stdout instead of stderr

Comment 1 Tomáš Hozza 2014-02-24 08:24:26 UTC
Hi.

Wget man page says for --quiet:
"Turn off Wget's output."

So from my point of view the behaviour is the same as expected. What makes you
think it should behave differently?

Comment 2 Micah Cowan 2014-02-24 16:22:33 UTC
A common feature request for wget has been to support a mode that displays _only_ progress information, without the rest of what shows up in verbose mode (a cross between -nv and -v?). I don't believe this has been implemented yet, and obviously it's a feature request, not a bug.

This report seems to include a separate feature request, which is to display progress on stdout instead of stderr. That'd be a bad idea for a number of reasons, the main one being that it would greatly interfere with using "wget -O -" and redirecting to a file or pipeline. Another reason is that stdout is meant for core data, and messages and information for the user (typically either displayed to the terminal, or to a log file) is what stderr was invented for (which makes "stderr" something of a misnomer).

Comment 3 Robert Strickler 2014-02-24 17:16:35 UTC
(In reply to Tomas Hozza and Micah Cowan from comments #1-2)

Micah is correct, when running wget from a script all that usually needs to be presented is a progress bar, the user probably doesn't need or want details about 302 redirects and whatnot, they just want to be reassured that the script has not stalled with a large transfer being done.
I threw the stdout suggestion as a way to separate the PB from the errors.
Micah makes some good points about stderr usage. How about sending it to a new fd tied to stderr so a script author could redirect it to his/her preference  with 3>&1 or allow the author to specify the fd on the option e.g "--progress=bar,1". Alternatively, log ONLY the messages when given --output-file or --append-output options on invocation and leave the progress on stderr. Even implementing both might not be a bad idea when futzing about with the innards of the command.
I still feel it is a bug, since a progress bar is requested but not shown. One might argue that the sequence of the options (progress then quiet should be switched so the logical inference is that the latter specification overrides the former. I could live with that as long as it was documented and an example provided in the man page.

Comment 4 Tomáš Hozza 2014-03-06 09:55:03 UTC
Hi.

I sent an email to the bugs-wget list with the description of your proposal
with your email address in the CC.

Closing as UPSTREAM...