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 -- 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