Comment 10 for bug 320035

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