Re: [PATCH/RFC] Fix for default pager

[Johannes Sixt <j.sixt@viscovery.net>]

Am 08.06.2010 19:28, schrieb Dario Rodriguez:
> On Tue, Jun 8, 2010 at 12:56 PM, Johannes Sixt<j.sixt@viscovery.net>  wrote:
>> Am 08.06.2010 16:39, schrieb Dario Rodriguez:
>>>
>>> On Tue, Jun 8, 2010 at 11:17 AM, Johannes Sixt<j.sixt@viscovery.net>
>>>   wrote:
>>>>
>>>>   $ GIT_PAGER=/is/not/there git log
>>>>   $ echo $?
>>>>   141
>>>>
>>>> That's SIGPIPE, just as I would expect.
>>>
>>> As I said in the original thread...
>>>
>>> $ PAGER=/nothing/here ../git log
>>> $ echo $?
>>> 0
>>
>> That's no surprise with your toy repository: git-log has run to completion
>> (without overrunning the pipe buffer) before the pager process that it
>> forked can even execute its first instruction.
>>
>
> I cannot understand what's the point... I'm running git without
> installing it, but why do you say "toy repository"?...

Your repository has only 2 commits and its git log output is less than 
1kB, i.e., sufficiently small to fit in a pipe's buffer.

git log calls start_command to fork() the pager. The OS's scheduler does 
not run the newly forked process immediately; rather, git log goes on with 
its own business, writing output to the pipe that connects to the pager. 
Because your repository is so small, git log never has to wait that the 
pager drains the pipe. git log finally reaches exit(0). At this time, an 
atexit() handler (wait_for_pager()) finally calls finish_command() to wait 
for the pager.

This is the first time that the forked child process can run. Only now it 
turns out that the pager cannot be run. The child process closes the pipe 
and exits with an error, but it is too late: wait_for_pager() drops the 
error return code of finish_command() to the floor. The parent process 
(git log) can complete with the exit code that it was given earlier, 0.

Repeat your experiment with ./git log in git.git itself to see the difference.

-- Hannes