Comment 2 for bug 387717

Robert Collins wrote:
> Well, I think there is a choice between tradeoffs.
>
> Its very hard for scripting to deal with progress bars and other such
> 'not the requested content' artifacts.
>
> CLI programs get precisely two file descriptors to write to.
>
That is not true. Two output handles are by default provided that are
(in the absence of redirection on the command line) connected to the
terminal.
Any program can use others, and bash even provides a mechanism for
redirecting them (e.g. 3>myfile).

The big issue (TM) is that output to STDERR should be limited to
important things the user must be informed about.
Cluttering that output with non-essential "noise" reduces the value of
that output channel significantly.

> Suggestions about how to improve the situation without making life
> harder for interactive or scripting users will be appreciated - but this
> isn't a casual decision that we took.
>
>
One realistic suggestion is to not output that progress bar at all
unless the user explicitly ASKS for it (presently due to bug 339385
and/or the lack of a config file option this is not possible). One could
also provide a config option to say which output channel to use (
default STDOUT).

Another improvement is to not output progress information if the POSIX
function isatty returns false. Look at what happens when the output was
redirected to a file (this is exactly what the file contains):

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