less
less copied to clipboard
gwsw
Page-up and up-arrow sometimes stop working at EOF.
Using less-561 beta.
I spend a lot of time viewing mail log files to which lines are continually being appended by various processes.
Often I'll page through the file using the keyboard 'space bar' and sometimes I'll reach the present EOF that way.
It seems that sometimes, if data has been appended to the file, after reaching the original EOF this way then attempting to page up from this original EOF using e.g. the 'page-up' and 'up-arrow' keys no longer works, and the display is somehow "stuck" at the original EOF. At this point there's nothing at all in the status line. It isn't a big deal, pressing CTRL-C restores the function of the navigation keys - this makes me wonder if the explanation is that I've somehow entered 'follow' mode (effectively tailing the file) without realizing it, and that less has simply not updated the screen and presented the appropriate prompt.
Unfortunately I don't yet have a reliable way of reproducing this. I'm not sure that this behaviour was not present in earlier versions - it may have been masked by #53. When I find a reliable way to reproduce it I'll test that.
Update: I'm also seeing the same "display stuck at the last line" thing happen if I just use 'down-arrow' to get to the EOF instead of the space bar. CTRL-C unsticks it, but once it's got into this state 'down-arrow', 'page-down' or the space bar all cause it to stick there again.
Strictly speaking I should have said that I'm trying to page past the line after the line after the original EOF (no that's not a typo - I mean to the second line after the original EOF, not to the line after the original EOF) with the keystrokes which cause the display to get stuck. If I use 'down-arrow' to get to the line after the original EOF the display is not stuck. And strictly speaking the display isn't permanently stuck, but (1) it hangs for several seconds (it's been up to 20 or so but more commonly five or ten - these are not fast machines) with the line after the original EOF displayed as the last line of the file, and (2) when it unsticks after I wait the few seconds for it to unstick by itself, if I use 'up-arrow' to attempt to scroll up one line then the last displayed line disappears and the status line then shows "(END)". If I then hit 'down-arrow' once, the line after the original EOF appears again and the "(END)" on the status line disappears! Using any of those keys to attempt to get beyond the first line after the original EOF does not show any more lines, even though there are many more lines after the original EOF, and causes it to stick. Using 'follow' of course sets a new EOF and the issue goes away until the next time something triggers it.
I have the feeling that using '/' to search for text may be involved. It may be that the text needs to be in the first line after the original EOF but I'm not sure about that yet.
New information.
I think that I can reproduce this issue on demand in my usual xterm. I haven't experimented with other xterm settings, and I think the number of lines displayed might be important.
In my xterm, which normally displays 62 lines of the file, I start 'less' to display a mail log file and then:
- Go to the end of the file. The status line says 'END'.
- Page back at least five pages and then scroll down one line.
- Wait for at least one line to be appended to the file by some other process (in my case, syslog).
- Page down to the end of the file and attempt to page down beyond that.
Result:
One line beyond the original EOF is displayed; the status bar does not say 'END'. If there is a current search string, the display sticks at EOF + 1 line; CTRL-C is required to un-stick it. If there is no current search string, the display does not stick at EOF + 1line. Using 'up-arrow' to go up one line to the original EOF causes 'END' to be displayed in the status bar.
If necessary I can probably provide test files to help in reproducing the issue.
I guess test files would help. I haven't been able to reproduce this based on your description. In step 1 I've tried both using "G" and paging down to the end. When I get to step 4, I always see "END" at the bottom of the screen. Usually the new lines are not displayed in step 4 because of buffering, but pressing R displays the new lines as expected. Can you also confirm what, if any, command line options you are using? The -b and/or -B options might be relevant if you are using them.
File attached. It's garbage grepped from a mail debug log. I had to lie about it to get github to accept it - it's compressed by 7z, not (pk)zip. I just renamed it.
-
Un7zip it and make a second copy.
-
Switch to another terminal and use less (no options needed for this demo) to view the file.
-
Go to the bottom of the file.
-
Page up ten times or so with the 'pg up' key.
-
Use '/' to search for 'NOQUEUE'.
-
Switch to the other terminal and append a copy of the same file to itself.
-
Back in the 'less' terminal, page down to the bottom of the file with the space bar.
When I do this, I see the first line of the text just appended to the file, and less seems to hang. In fact FWIW it's chewing up 90% CPU for a while, and eventually control returns, but then it still has the wrong line at the bottom of the window (it's still the first appended line, not the original last line) and the status bar doesn't say 'END'. Using 'up-arrow' once gets back to the correct line and the 'END' appears in the status bar. Press 'down-arrow' once and I see the line after EOF as I mentioned; if I press 'down-arrow' again less start chewing CPU again. Once it's got into this state it seems to stay there, so attempting to go to the second appended line with 'down-arrow' causes less to start chewing CPU again. Pressing 'F' (when 'less' will listen) recovers from the apparently confused understanding of EOF (and less now goes to the new EOF) until the next time something is appended to the file and the page-up/page-down procedure is repeated. Unfortunately I page up and down in mail logs more or less all day long.
This problem still appears to be present in the latest beta (580).
Configured --with-regex=pcre2, otherwise vanilla, but the same problem was evident without pcre2.
I haven't yet verified if the long (seconds to minutes) hangs are still an issue if I try to move past EOF when the issue rears its head, but at least the behaviour which I described in my previos post is still present. ('END' shows at what was originally the EOF, but after text has been appended to the file 'END' appears only when the original EOF line is at the bottom of the screen; it disappears when the next line is displayed an no further lines can be seen evn though there are more lines there in the file).
As a result of this rather painful experience I am now using less less.
I have tried numerous times to reproduce this, on a Linux system, on a MacOS system and on Windows, and have not been able to do so. When I run your instructions, in step 7 it stops and prints (END) when it gets to the end of the buffered part of the file, and then if I type R it loads the new text and I can page through it normally. I do not know what is different in your environment that is causing this problem for you.
Thanks for trying.
This is all on Linux only. If you want to pursue it I could send you a VM to demonstrate the problem - I'm seeing it on the VM that I use here as my mail server. Partly because of the trouble with less, but mostly because I can do more with a Web interface, for a few months I've been working on something which eliminates the need for a lot of the log-trawling that I have been doing for what seems like decades.
That means I've been relying less on less so it isn't the show-stopper that it was last year. If you don't think it's going to be effective use of your time to track this down I can live with it now. It's only the mail log trawling that causes the grief, I use less a lot for many other paging tasks with no problems.
I don't use the R command. The problem happens when I use page-down or down-arrow at what originally was EOF, but is no longer. I get just one line of the newly appended text displayed. Quite often less also hangs at that point, but it reliably gets the END wrong.
Or at least it did hang. There might have been an improvement in the performance. In the past, after paging past what had been EOF and it hangs, after 30 seconds or more I've sometimes had to kill and restart less because apparently it wasn't ever going to recover. That doesn't seem to have happened since I started using version 580, but of course that could just be luck - it always did seem to be a bit intermittent and I haven't been using it long, nor anything like so intensively, as I used to use it.
The hang you were seeing might be related to #111. In 2df9dca3460a678d42aec122bdccb1dccb7384f1 I added a change to reduce the number of visual bells sent to the terminal when you try to scroll past EOF.
That seems plausible, if it would affect me even though I don't use the visual bell.
I'll look out for it and let you know after I think I'm confident one way or the other.
If it is indeed the case, then as far as I'm concerned the problem becomes almost cosmetic. The issues then would be that until after a seek to the new EOF, the END indication would indicate the original end of buffer; the line displayed as the alleged end of buffer would be the line after that; and the rest of the newly appended text would not be visible. Seeking to the new EOF would correct all that.
Confirmed that this problem persists in beta version 580.
See my description of May 23 2020. Perhaps note in particular that the problem appears only when there is a current search string?
Additional information (latest beta, 580 - I do not know if this is true of older versions).
After a single down-arrow, when the status line 'END' notice disappears, it is replaced by the colon (':') character. After a second down-arrow, the colon character disappears and is not replaced by anything else. The cursor is then at the start of an entirely blank status line.
At this point less appears to hang. CTRL-C now seems reliably to unhang it (that was not the case in earlier versions, it was unreliable) and the colon reappears. Then pressing 'R' causes the message "calculating line numbers" to appear and normal operation seems to be resumed.
I'm beginning to suspect that the hang which I've mentioned is actually the line number calculation taking place without displaying the message.
I hope some of this might at least help narrow it down.
I've never been able to reproduce this following the steps in this report. Please reopen with instructions to reproduce if it still happens with less-643.
Using less-644 I think we can say that this is fixed.
A very minor issue seems to have crept in however. I noticed that sometimes after using 'F' to get to the bottom of one of my mail logs, sometimes if I hit up-arrow I unexpectedly find myself back at the top of the file. It doesn't seem to happen every time. Nothing locks up and it's trivial to get back to EOF so no big deal. Just thought you'd like to know. I'm pretty sure less-608 and earlier never did this.
I haven't used 609-643 inclusive.