SIGPIPE handling (Re: [PATCH v3 0/3])

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Jeff King wrote:

> Less robust than that is to just ignore SIGPIPE in most git programs
> (which don't benefit from it, and where it is only a liability), but
> then manually enable it for the few that care

This seems backwards.  Aren't the only places where it is just a
liability places where git is writing to a pipe that git has created?

We could keep the benefits of SIGPIPE (including simpler error
handling and lack of distracting EPIPE message) in most code, and only
switch to SIGPIPE-ignored semantics where the signal has a chance to
cause harm.  Maybe run_command should automatically ignore SIGPIPE
when creating a pipe for the launched command's standard input (with a
flag to ask not to), as a rough heuristic.

There's a subtlety I'm glossing over here, which is that for commands
that produce a lot of output (think: "git fetch --all"), output may
still not the primary goal.  I think even they should not block
SIGPIPE, to follow the principle of least surprise in the following
interaction:

	git fetch --all 2>&1 | less
	... one page later, get bored ...
	q (to quit)

Most Unix programs would be killed by SIGPIPE after such a sequence,
so I would expect git to be, too.

Just my two cents,
Jonathan