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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 18, 2012, 10:06 UTC
Message-ID: <20120218100517.GA8998@burratino>
In-Reply-To: <20120218085221.GA13922@sigill.intra.peff.net>

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