SIGWINCH support for progress bar

Bug #316357 reported by Per Johansson on 2009-01-12
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Wishlist
Vincent Ladeuil
Declined for 1.18 by Vincent Ladeuil
Declined for 2.0 by Vincent Ladeuil

Bug Description

Bordercase that I should even report it, but I tend to resize my terminals a lot, and when going from bigger to smaller the progress bar messes up the terminal a bit. Would be great if you could add SIGWINCH support for the progress bar, so it adjusts when the terminal size changes

Related branches

John A Meinel (jameinel) on 2009-01-12
Changed in bzr:
importance: Undecided → Wishlist
status: New → Triaged

There are other parts like log --line that also know about the
terminal width. We probably want a cache of the width after it's been
seen, and to update that from sigwinch.

Robert Collins (lifeless) wrote :

On Mon, 2009-01-12 at 22:17 +0000, Martin Pool wrote:
> There are other parts like log --line that also know about the
> terminal width. We probably want a cache of the width after it's been
> seen, and to update that from sigwinch.

I suggest a callback code inside bzrlib can register for, which the
signal handler can trigger.

-Rob

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Martin Pool (mbp) on 2009-06-19
tags: added: progress
Samuel Bronson (naesten) wrote :

I want this even more for the reverse case -- when I resized the terminal specifically because the progress text is getting cut off right before the interesting part.

(But I have to wonder: how often will someone resize their terminal in the middle of a log --line which isn't going to a pager?)

Vincent Ladeuil (vila) wrote :

The associated branch contains a trivial implementation to catch SIGWINCH.

I tested it by running 'bzr selftest -s bt.test_http' and this reveals a fundamental flaw: catching the signal can interrupt an IO and if the code base is not ready to handle that, we can get weird failures.

I don't know if it's worth handling for a cosmetic benefit but people can play with it in a plugin if they really want and have valid use cases for that.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
> The associated branch contains a trivial implementation to catch
> SIGWINCH.
>
> I tested it by running 'bzr selftest -s bt.test_http' and this reveals a
> fundamental flaw: catching the signal can interrupt an IO and if the
> code base is not ready to handle that, we can get weird failures.
>
> I don't know if it's worth handling for a cosmetic benefit but people
> can play with it in a plugin if they really want and have valid use
> cases for that.
>
> ** Branch linked: lp:~vila/bzr/316357-SIGWINCH
>

I thought most of our IO cases trapped EINTR. At least, I thought we
tried to do that.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksf4KwACgkQJdeBCYSNAANlCgCgqFvfyLkcDUyTRBwTDT51BKIH
jcAAoKEEhfZl/ZskEG3G6yyAYtQWBIX3
=hLQa
-----END PGP SIGNATURE-----

Martin Pool (mbp) wrote :

2009/12/10 John A Meinel <email address hidden>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vincent Ladeuil wrote:
>> The associated branch contains a trivial implementation to catch
>> SIGWINCH.
>>
>> I tested it by running 'bzr selftest -s bt.test_http' and this reveals a
>> fundamental flaw: catching the signal can interrupt an IO and if the
>> code base is not ready to handle that, we can get weird failures.
>>
>> I don't know if it's worth handling for a cosmetic benefit but people
>> can play with it in a plugin if they really want and have valid use
>> cases for that.
>>
>> ** Branch linked: lp:~vila/bzr/316357-SIGWINCH
>
> I thought most of our IO cases trapped EINTR. At least, I thought we
> tried to do that.

If we have any code that doesn't handle eintr, it can obviously fail
in other cases. Catching this may make it somewhat more likely but
probably not a lot. So let's do it.

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

Vincent Ladeuil (vila) on 2009-12-16
Changed in bzr:
assignee: nobody → Vincent Ladeuil (vila)
status: Triaged → Fix Committed
milestone: none → 2.1.0rc1
Vincent Ladeuil (vila) on 2009-12-16
Changed in bzr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers