Re: [Announce] GIT v1.5.0-rc2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,
I'm not sure if you are still interested in this, but I have posted a beta release of less (less-401) which I believe fixes both of these problems. See http://www.greenwoodsoftware.com/less. If you try it, let me know how it works for you.

--Mark


On 1/23/2007 12:32 PM, Linus Torvalds wrote:
[ Added "less" author Mark Nudelman to Cc: ]

On Tue, 23 Jan 2007, Bill Lear wrote:
I can't seem to get this to work, no matter what I do, using the
latest 1.5.0-rc2 code.  I have the environment variables LESS, PAGER,
PAGER_FLAGS, and I can't seem to get 'git diff' to not plough through
my screen each time it is run, no matter the combinations...  Could
someone post the magic?

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

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]