bzr with bzr+ssh noisy and output muddled.

[David Ingamells]

Martin Pool wrote:
> Yes, there are bugs open about having a way to disable the progress
> bars and to have them properly synchronized with other output.
> They're assigned to me and I'll try to fix them soon.
>
> If people don't like this going to stderr what do they want?
>   
I want to be able to still see real error messages if they arise without 
the terminal output being
cluttered with progress bars even for activities that only take a few 
seconds. For a command that
takes minutes a progress bar can be reassuring, but for activities that 
finish in seconds???

On the whole I suspect that such progress bars are most useful to the 
developers of the tool itself. Others, especially occasional users, 
don't always know how to interpret them - for example the progress bar 
during a "bzr branch" I just tried with a large repos and 1.15.1 is very 
jittery and resets several times - it seems to be several consecutive 
progress bars, each of which starts counting again. I've seen other 
tools (not bzr) that show progress at 100% and then take another age 
(possibly 50% of the real total run-time) to finish.
> 0 - Bugs regarding it cluttering other output fixed? ok, of course.
> 1 - An option to just turn it off?  ok, that too should be fixed.
>   
That option should also be available in the config file. Hopefully with 
the default being OFF.
If people want progress bars they should ask for them. That fits better 
with the UNIX philosophy.
> 2 - The progress bar sent to stdout?  That seems even worse, because
> stdout is fairly often, even for commands that show progress, going to
> be eg a patch or a log you want to redirect into another file.
>   
Definitely not! Unless there is an option available and used to 
explicitly ask for it to go there. Especially for commands like "status" 
the stdout output should be clean and uncluttered. I have scripting that 
uses that output. This is one area where bzr is not always optimal - it 
is sometimes forgotten that a CLI tool should behave well when used from 
a script, especially with commands whose purpose is to provide 
information (e.g. "status" and "missing").
>
> At the moment we only show progress if stderr isatty, so this command
> at present would give you just the errors in log.err but no progress
> at all.
>
>   
I've seen the following output  when it was redirected to a file with "> 
file 2>&1" (this is exactly what the file contains) but that might have 
been 1.10, I cannot reproduce it this morning with 1.15.1:

[/                   ] Build phase 0/2

[-                   ] Build phase:Building tree 0/1037

[\                   ] Build phase:Adding file contents 33/1037

[##|                 ] Build phase:Adding file contents 320/1037

[#####/              ] Build phase:Adding file contents 625/1037

[######-             ] Build phase:Adding file contents 769/1037

[########\           ] Build phase:Adding file contents 938/1037

[#########|          ] Build phase 1/2

[#########/          ] Build phase:Apply phase 0/2

[#########-          ] Build phase:Apply phase:removing file 0/1

[##############\     ] Build phase:Apply phase 1/2

[##############|     ] Build phase:Apply phase:adding file 0/16


> Using /dev/tty may make things a bit harder to test or to script.  Are
> there other problems?
>   
Detached scripts (e.g. daemons) don't have access to /dev/tty