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): 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.
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 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?
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? : 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.
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.