On 1/23/2007 12:32 PM, Linus Torvalds wrote:
I think "less" is actually seriously buggy with -F.
There are two bugs:
- it will always screw up the screen and move to the end. It does this
even if you use -FX which should disable any init sequences, so it's
not about that problem.
- if you resize the terminal while less is waiting for input, less
will exit entirely without even showing the output. This is very
noticeable if you do something like "git diff" on a big and cold-cache
tree and git takes a few seconds to think, and then you resize the
window while it's preparing. Boom. No output AT ALL.
Both bugs are easily seen with this simple command line
clear ; (sleep 5 ; echo Hello) | less -F
where you would EXPECT that the "Hello" would show up at the first line of
the screen (since we cleared the screen and moved to the top left corner),
but in fact it doesn't.
And try resizing the terminal to make it bigger during the five-second
pause, and now you'll see less not show the "Hello" at _all_. It's just
gone (this is true even if the output was _more_ than a screen: try with
(sleep 10 ; yes ) | less -F
and resize the screen, and it will exit silently after 10 seconds - never
showing any output at all! Even though the output is obviously bigger than
a screen..
Tested with Kterm, gnome-terminal and xterm. They all behave the same for
me.
I don't know exactly what the bug is, but I find the "eof" handling very
confusing in the less sources. It makes me suspect that there is something
that gets confused by the partial read, sets EOF (since we're on the last
line), and then thinks that it should quit, since EOF is set.
I dunno. Mark?
Linus
Hi Linus,
The first issue that you mention (that we move to the bottom of the
screen before printing the first line) is behavior that has always
existed in less. It's not the init sequence that's doing it; less
deliberately moves to lowerleft before printing any output that is
intended to go at the bottom of the screen, including both file data and
the prompt. This was a design decision from the first version of less,
and I've never been brave enough to try to find all the places that
would be affected by changing this. For example, less tries to keep
track of exactly what's displayed on the screen at all times, and it's
harder to do this if we don't know whether some output scrolled the
screen or not. It may or may not be a big job to make all the changes
that would be required. I will move this up the priority list and take
a look at it for the next release of less.
BTW, this issue is documented as enhancement request #112 at
http://www.greenwoodsoftware.com/less/bugs.html.
Your second issue is definitely a bug. Less's handling of -F and eof in
general is indeed rather baroque and confusing, and probably needs a
complete revision. Some of the complexity comes from being portable to
many (not necessarily Unix-like) systems. But in this case, I think the
early exit is happening because less makes the decision about whether to
quit due to -F based on the state of the input when the first prompt
occurs. When less receives SIGWIND, it repaints the screen and
*reprompts*. So if it gets this signal before the first screen is
completely filled, it tries to prompt, somehow gets confused and thinks
that the partially filled screen is evidence of a short file, and exits.
I will add this to the bug list and try to fix it in the next release.
--Mark
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html