progress bar is shown regardless of the --quiet option

[Christophe Simonis (OpenERP)]

in at least pull and revert commands

[Martin Pool (mbp)]

I guess it should not be.

[Aaron Bentley (abentley)]

-----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)]

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.

[Christophe Simonis (OpenERP) (kangol)]

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)]

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)]

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)]

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

[Robert Collins (lifeless)]

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

[Martin Pool (mbp)]

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/>

[Steve McInerney (spm)]

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 :-)