Red Hat Bugzilla – Bug 120916
appending cause less to show nonexisting linebreaks
Last modified: 2007-11-30 17:10:40 EST
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):
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.
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.
Pressing > will view the end of the file correctly. (Like it would
look if you pressed < followed by >)
A typical example of a file causing this behaviour would be the output
from a wget command.
This bug also exist in FC3.
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.
I can reproduce only this case:
1) we need to have a file of lines that is bigger than the total lines displayed
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 '>'
The original file is separated by bogus newline between the old file and the new
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?
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.
Could you please test this version of less? :
I added a repaint call in case after '>' is processed so the bogus line display
should be fixed by it.
Ok, the new less-382-8 is now built.
I have just seen the problem again on FC5 with less-394-3.
Fixed in less-394-5.
AFAICT 394-3 is the newest less for FC5.