Re: [Announce] GIT v1.5.0-rc2
- From
- Mark Nudelman <markn@greenwoodsoftware.com>
- Date
- Jan 24, 2007, 17:54 UTC
- Message-ID
- <45B79D68.6040200@greenwoodsoftware.com>
- In-Reply-To
- <Pine.LNX.4.64.0701231157430.32200@woody.linux-foundation.org>
On 1/23/2007 12:32 PM, Linus Torvalds wrote:
Show 43 quoted lines
> 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