Am 08.06.2010 19:28, schrieb Dario Rodriguez:
On Tue, Jun 8, 2010 at 12:56 PM, Johannes Sixt<j.sixt@xxxxxxxxxxxxx> wrote:
Am 08.06.2010 16:39, schrieb Dario Rodriguez:
On Tue, Jun 8, 2010 at 11:17 AM, Johannes Sixt<j.sixt@xxxxxxxxxxxxx>
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
--
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