bzr with bzr+ssh noisy and output muddled.

[Martin Pool]

2009/6/17 David Ingamells <david.ingamells at mapscape.eu>:

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

I agree, though it's sometimes a bit hard to tell how long something
will take til you try it.  I agree there should be better heuristics,
like we could just try not drawing one for a few seconds - though that
might be surprising too.

My experience is these things are hard to design in advance, you have
to try them - and then be a bit better at fixing the fallout than we
(I) have been recently.

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

That's a bug too.

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

That is true for many unix programs - many have no option at all, and
in some like e2fsck or rsync you have to ask for it.  On the other
hand many do show them by default (apt, wget, curl).  But, I'm not
really open to changing this at the moment, because showing them is
part of the experience we want: things should be fast, and when they
do take nontrivial time either because of machine limits or bzr
limits, we'll show we're making progress.  But we'll certainly try to
keep them out of your way.

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

Yes, that's <https://bugs.edge.launchpad.net/bzr/+bug/387717>.  Thanks
for filing it.  I'm working on it now.

There's also https://bugs.edge.launchpad.net/bzr/+bug/320035 that
--quiet should turn them off but doesn't.

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

But that seems like a feature - for such things you almost certainly
don't want a progress bar.

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