Bug 159208 - yum progress bars scroll down the screen
Summary: yum progress bars scroll down the screen
Status: RESOLVED DUPLICATE of bug 160422
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 2.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-12 22:10 UTC by Orion Poplawski
Modified: 2008-04-09 19:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
urlgrabber output (268 bytes, text/plain)
2008-03-17 19:00 UTC, Orion Poplawski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Orion Poplawski 2008-03-12 22:10:06 UTC
Version:           2.0 (using KDE 4.0.2)
Installed from:    Fedora RPMs
OS:                Linux

When running yum in a konsole window, I get output like:


Downloading Packages:
(1/1): libX11-debuginfo-1   0% |                         | 8.0 kB    05:00 ET
(1/1): libX11-debuginfo-1   0% |                         |  16 kB    04:57 ET
(1/1): libX11-debuginfo-1   0% |                         |  24 kB    04:42 ET
(1/1): libX11-debuginfo-1   1% |                         |  40 kB    04:15 ET

i.e., it scrolls down the page rather than overwritng the same line.  Works fine in xterm.

Version-Release number of selected component (if applicable):
kdebase-4.0.2-2.fc9.i386
Comment 1 Robert Knight 2008-03-13 01:34:06 UTC
Do you know of any cross-distribution programs which exhibit a similar problem, with different behavior between Xterm and Konsole?
Comment 2 Orion Poplawski 2008-03-13 17:36:59 UTC
Well, yum is using urlgrabber to do the downloading, so it's really the output from that.  Not really sure how "cross-platform" that is since it was developed to support yum.

http://linux.duke.edu/projects/urlgrabber/

Cannot reproduce with wget or scp.
Comment 3 Robert Knight 2008-03-17 18:17:09 UTC
If you can capture the output which is sent to the terminal then you can paste it here and I can replay it to see the effect.
Comment 4 Orion Poplawski 2008-03-17 19:00:02 UTC
Created attachment 23936 [details]
urlgrabber output

Looks like urlgrabber is outputting <CR> (ctrl-M) and expecting it not to
newline, which it shouldn't.

$ stty -a
speed 38400 baud; rows 29; columns 77; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

Basically identical for the xterm case.
Comment 5 Robert Knight 2008-03-17 19:26:41 UTC
When I cat the file attached in comment #4 I only see one line of output, which shows the progress bar at 100% as expected because the previous output on the line gets immediately overwritten.  Is this the case for you?

> Looks like urlgrabber is outputting <CR> (ctrl-M) and expecting it not to
> newline, which it shouldn't. 

I don't think it is as simple as that.  The Konsole code which handles <CR> is really simple, it just sets the cursor position back to the start of the current line.  
I also get the same results for 'echo -e "\r"' in xterm and Konsole.
Comment 6 Robert Knight 2008-03-17 19:36:55 UTC
Running urlgrabber on its own with the syntax:

urlgrabber <URL> test

Produces the correct result for me, with the progress bar overwriting the current line on each update.
Comment 7 Orion Poplawski 2008-03-18 00:15:02 UTC
Found the issue.  konsole size was 78 characters wide so the lines wrap to the next line.  Sorry about that.
Comment 8 Kevin Kofler 2008-04-09 19:45:45 UTC
Actually a dupe of #160422.
Comment 9 Kevin Kofler 2008-04-09 19:46:02 UTC

*** This bug has been marked as a duplicate of 160422 ***