Bug 120916 - appending cause less to show nonexisting linebreaks
Summary: appending cause less to show nonexisting linebreaks
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: less
Version: rawhide
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Ivana Varekova
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-04-15 07:51 UTC by Kasper Dupont
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version: less-394-5
Clone Of:
Environment:
Last Closed: 2006-10-25 11:01:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Kasper Dupont 2004-04-15 07:51:08 UTC
Description of problem:
If a file viewed with less grows while it is being viewed, it can be
viewed incorrectly by less. Going to the end of the file a few times
produce corrupt view of the file.

Version-Release number of selected component (if applicable):
less-382-1.1

How reproducible:
Happens always

Steps to Reproduce:
1. Open a file that does not end with a newline
2. Press > to go to the end of the file
3. Wait for more characters to be appended (and still no newline)
4. Press > again
5. Press the cursor down key.

Actual results:
Pressing > the second time does not show the new data. Instead it
beeps as if you were already at the end of the file, and updates the
status line now showing 99%. Pressing down cause the new characters to
be shown with a nonexisting linebreak on the last line of the file.

Expected results:
Pressing > will view the end of the file correctly. (Like it would
look if you pressed < followed by >)

Additional info:
A typical example of a file causing this behaviour would be the output
from a wget command.

Comment 1 Kasper Dupont 2005-03-31 18:58:43 UTC
This bug also exist in FC3.

Comment 2 Kasper Dupont 2005-08-31 16:05:42 UTC
This bug also exist in FC4 with less-382-7. I noticed that the bug manifest
itself slightly different with and without line chopping enabled. But in both
cases > produce a wrong result.

Comment 3 Jindrich Novy 2005-09-02 06:51:56 UTC
I can reproduce only this case:

1) we need to have a file of lines that is bigger than the total lines displayed
on terminal.
2) display the file with less and press '>' to move to the end
3) add some characters to a new line(s) of the viewed file at the end
4) press '>'

you see:
The original file is separated by bogus newline between the old file and the new
characters added.

If this is the bug you see, it seems like a displaying problem of the less as if
you move using your cursor keys up and down, letting the added line to desappear
from the screen, you'll see the correct file content. (without the bogus
newline) And it doesn't depend much on whether the viewed file ends up with
newline or not.

Is this the bug you see?

Comment 4 Kasper Dupont 2005-09-02 09:59:18 UTC
I'm only able to reproduce the problem if the file did not end with a newline at
the time > was pressed. If there was a newline in the end of the file moving
forward correctly displays any appended data.

When the problem does appear, using cursor up and down does not immediately
solve it. Only if I scroll far enough to have the bogus newlines outside the
visible screen area does the problem go away.

I can also reproduce the problem if the file is shorter than one window, but
still I must press > before appending more characters to reproduce the problem.

Comment 5 Jindrich Novy 2005-09-02 11:37:08 UTC
Could you please test this version of less? :

http://people.redhat.com/jnovy/files/less-382-8.src.rpm

I added a repaint call in case after '>' is processed so the bogus line display
should be fixed by it.

Comment 6 Jindrich Novy 2005-09-06 10:34:31 UTC
Ok, the new less-382-8 is now built.

Comment 7 Kasper Dupont 2006-08-22 20:38:50 UTC
I have just seen the problem again on FC5 with less-394-3.

Comment 8 Ivana Varekova 2006-10-25 11:01:06 UTC
Fixed in less-394-5.

Comment 9 Kasper Dupont 2006-12-19 15:09:05 UTC
AFAICT 394-3 is the newest less for FC5.


Note You need to log in before you can comment on or make changes to this bug.