progress bar is shown regardless of the --quiet option

Bug #320035 reported by Christophe Simonis (OpenERP) on 2009-01-22
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Martin Pool
bzr (Debian)
Fix Released
Unknown

Bug Description

in at least pull and revert commands

Related branches

Martin Pool (mbp) wrote :

I guess it should not be.

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> I guess it should not be.

I'm a bit more hesitant about that. I don't think not wanting notes or
warnings is the same as not wanting progress. After all, we do already
provide a way of disabling the progress bar via an environment variable.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl+ccAACgkQ0F+nu1YWqI1BXgCfVhlUS9Qc6HpBHMBDc2KacIvd
ltIAn2WCzzSR42IsjnJnyp8LgnJSVwBh
=xtWc
-----END PGP SIGNATURE-----

Martin Pool (mbp) wrote :

Fair enough - I'd like to know more about why it's not being shown. In a cron job or a situation with no terminal, it shouldn't be shown.

Changed in bzr:
importance: Medium → Low
status: Confirmed → Incomplete

OK. I wasn't aware of the environment variable. It's not very well documented.
Also an environment variable may have side effects.
Why not a command line option and/or an entry in bazaar.conf like other options ?

Martin Pool (mbp) wrote :

So where are we going with this bug? It seems like we should go back to the use case where you want the bar not to be shown. What is it?

Steve McInerney (spm) wrote :

Just hit this ourselves.

Have an automated/cron:
if (bzr st) then bzr ci -q -m "updated"

kind of logic/situation.

See errors? sure.
Warnings... maybe - ideally they could be thrown away by -qq semi-standard style of "super quiet".

But the progress bar should not be shown at all. Esp as that leads to a resulting output with mixed "^M"'s in it.
Made worse as the progress bar appears to be going to stderr, not stdout - which is where I'd have expected it to be?

Martin Pool (mbp) wrote :

On the whole I think it probably is reasonable to suppress it.

Changed in bzr:
status: Incomplete → Confirmed
Robert Collins (lifeless) wrote :

On Fri, 2009-05-08 at 09:18 +0000, Steve McInerney wrote:
> Just hit this ourselves.
>
> Have an automated/cron:
> if (bzr st) then bzr ci -q -m "updated"
>
> kind of logic/situation.

If you're in a scripting environment you may want to set
BZR_PROGRESS_BAR=none

as you won't want progress bar output from 'bzr st' *either*.

Martin - I think this is still invalid, because of the above.

-Rob

2009/6/17 Robert Collins <email address hidden>:
> On Fri, 2009-05-08 at 09:18 +0000, Steve McInerney wrote:
>> Just hit this ourselves.
>>
>> Have an automated/cron:
>> if (bzr st) then bzr ci -q -m "updated"
>>
>> kind of logic/situation.
>
> If you're in a scripting environment you may want to set
> BZR_PROGRESS_BAR=none
>
> as you won't want progress bar output from 'bzr st' *either*.
>
> Martin - I think this is still invalid, because of the above.

In cron, if tty detection is working correctly (see bug 387717) you
should not get any problems, regardless of setting.

If all the other bugs are fixed I'm ambivalent about whether in an
interactive terminal -q should turn off progress bars.

--
Martin <http://launchpad.net/~mbp/>

On Wed, 2009-06-17 at 06:38 +0000, Robert Collins wrote:
> On Fri, 2009-05-08 at 09:18 +0000, Steve McInerney wrote:
> > Just hit this ourselves.
> >
> > Have an automated/cron:
> > if (bzr st) then bzr ci -q -m "updated"
> >
> > kind of logic/situation.
>
> If you're in a scripting environment you may want to set
> BZR_PROGRESS_BAR=none

Ta.

> as you won't want progress bar output from 'bzr st' *either*.
>
> Martin - I think this is still invalid, because of the above.

I disagree:

* It breaks expected behaviour.
If I run any tool with a "pls to be quieter" option, I expect it to be
quieter. Provide minimal to no information. Usually only errors.
If I run with the "pls to be quieter and I really mean it" option (eg
-qq) I expect zero output unless something breaks badly. ie Only see
fatal smashed and burning errors.
eg wget
wget'ing a URL, gives a progress bar, and simple and useful status.
wget -q, gives no status or progress

* I can't recall ever having to set an ENV variable to disable unwanted
output for a specific tool.
  - '-q' option, or similar, sure
  - send stdout to /dev/null, sure
These are expected methods and well understood. Using an ENV may well be
superior for all sorts of good reasons; but it's banging up against a
lot of years of accepted precedent and behaviour.

* $ bzr help ci
"-q, --quiet Only display errors and warnings."
a progress bar is neither error nor warning. Recognising that
documentation may be changed :-)

Martin Pool (mbp) on 2009-08-20
Changed in bzr:
importance: Low → Medium
Changed in bzr (Debian):
status: Unknown → Confirmed
Martin Pool (mbp) on 2010-01-15
Changed in bzr:
assignee: nobody → Martin Pool (mbp)
status: Confirmed → In Progress
John A Meinel (jameinel) on 2010-01-21
Changed in bzr:
milestone: none → 2.1.0rc1
status: In Progress → Fix Released
Changed in bzr (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.