bzr: BZR_PROGRESS_BAR is ignored

Bug #339385 reported by James Westby
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Fix Released
High
Martin Pool
bzr (Debian)
Fix Released
Unknown

Bug Description

Imported from Debian bug 517770:

Package: bzr
Version: 1.12-1
Severity: normal

When I run any of the folowing, I get progress output appropriate for a TTY:

BZR_PROGRESS_BAR=none bzr commit
BZR_PROGRESS_BAR=dots bzr commit
BZR_PROGRESS_BAR=none bzr missing

This does not look good under emacs :-(.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-2-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages bzr depends on:
ii libc6 2.7-15 GNU C Library: Shared libraries
ii python 2.5.2-1 An interactive high-level object-o
ii python-central 0.6.7 register and build utility for Pyt

Versions of packages bzr recommends:
ii bzrtools 1.12.0-1 Collection of tools for bzr
ii ca-certificates 20080809 Common CA certificates
pn python-paramiko <none> (no description available)

-- no debconf information

Related branches

Martin Pool (mbp)
Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Changed in bzr:
importance: Undecided → Unknown
Revision history for this message
Samuel Bronson (naesten) wrote :

It looks like the progress output is now being handled in bzrlib.ui or bzrlib.ui.text, and the BZR_PROGRESS_BAR environment variable isn't used in deciding which of the two to actually use?

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 339385] Re: bzr: BZR_PROGRESS_BAR is ignored

2009/4/12 Samuel Bronson <email address hidden>:
> It looks like the progress output is now being handled in bzrlib.ui or
> bzrlib.ui.text, and the BZR_PROGRESS_BAR environment variable isn't used
> in deciding which of the two to actually use?

That is correct, and that's the bug. We should either support it or
provide a better mechanism to choose the ui.

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

Revision history for this message
David I (david-ingamells) wrote :

IMHO the default should be "none" and there also needs to be an option setting available in the bzr config file.
David.

Revision history for this message
Vincent Ladeuil (vila) wrote :

While still not perfect (some edge cases needs to completely disable the progress output,
see bug #387717), the following goes a long way to address the problem under
emacs (part of my .bashrc):

# If we are inside an emacs shell, tell bzr it can use a text UI
# an a tty progress bar
emacs_shell=`echo $INSIDE_EMACS | grep comint`
if [ "$emacs_shell" != "" ] ; then
    export BZR_USE_TEXT_UI=1
    export BZR_PROGRESS_BAR=tty
fi

Martin Pool (mbp)
Changed in bzr:
assignee: nobody → Martin Pool (mbp)
importance: Medium → High
status: Confirmed → In Progress
Revision history for this message
Martin Pool (mbp) wrote :

Does anyone care about or use the dots-style progress view?

Revision history for this message
Martin Pool (mbp) wrote :

Fix now ready for review here: https://code.edge.launchpad.net/~mbp/bzr/339385-set-progress-bar/+merge/7534

Some more work can be done:

* This doesn't re-add a dots progress bar, so you either get the full tty mode, or nothing. There are some cases where you do care to see some indication that *something* is happening, but you can't repaint a progress bar, and dots accommodated that. I never thought it looked very good or was very useful; you basically get a screen full of dots. If people do care about this case, please file another bug. Perhaps, as suggested on the list, bzr should instead respond to SIGUSR1 to print out just one line about its current status?

bug 387717 is about David I's issue of not wanting it sent to stderr, or not by default.

bug 388275 asks for a config file setting for this.

Changed in bzr:
status: In Progress → Fix Committed
Revision history for this message
John A Meinel (jameinel) wrote :

Last I knew, the Launchpad puller was using Dots to check for activity. (If nothing was written to stdout for XX seconds it would kill the process.)

I have no idea if they are still doing so.

Revision history for this message
Martin Pool (mbp) wrote :

2009/6/17 John A Meinel <email address hidden>:
> Last I knew, the Launchpad puller was using Dots to check for activity.
> (If nothing was written to stdout for XX seconds it would kill the
> process.)
>
> I have no idea if they are still doing so.

mwhudson tells me they are not, they provide their own UI object.

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

Martin Pool (mbp)
Changed in bzr:
milestone: none → 1.17
status: Fix Committed → Fix Released
Vincent Ladeuil (vila)
Changed in bzr (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.