On Tue, Jul 22, 2008 at 02:17:43AM -0700, Junio C Hamano wrote: > Another slight worry I have is if the now-parent git process does the > right thing when the user kills the pager without viewing the output to > the end. git itself will get stuck with write() while the user is > reading, and then notice that the pipe does not have any more reader when > the pager is killed. This fact itself won't change by swapping the > parent-child relationship, but would we get a sensible behaviour after > that, or have we been ignoring what happens afterwards only because our > exit status has been hidden behind the pager? Running "git log" and > killing it by "q" (my pager is "less") makes it exit with 141. Hmm, good point. Though previously in this case, we were getting whatever code the pager provided. Which means nobody probably cared that much. Though I suppose that people who use "$?" in their prompt might see scariness. > I shouldn't worry, if everything is written correctly in the other parts > of the system, this swap should not have much ill effect. I am a little unhappy about the git process hanging around, but I don't know if it is worth making a meta-process just to manage the pager. Also, I think people with a pager that has spaces in in it will now need to quote it (e.g., PAGER="/path with space/less" used to work, but now is passed to the shell). Arguably, this brings it in line with other spawned programs, like EDITOR, but it is a difference, and we are in release freeze. That could be fixed with some magic in run_command. (Note that it has always been run by the shell under Windows, so again, this is making things more consistent). > By the way [2/2] was not signed-off. Just forgotten? Yes, forgotten. If you are planning on applying, please forge (and squash the portability fix). -Peff -- 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
