[RFC/PATCH] avoid SIGPIPE warnings for aliases

When git executes an alias that specifies an external command, it will complain if the alias dies due to a signal. This is usually a good thing, as signal deaths are unexpected. However, SIGPIPE is not unexpected for many commands which produce a lot of output; it is intended that the user closing

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Am 04.01.2013 13:47, schrieb Jeff King: > I have two reservations with this patch: > > 1. We are ignoring SIGPIPE all the time. For an alias that is calling > "log", that is fine. But if pack-objects dies on the server side, > seeing that it died from SIGPIPE is useful data, and we are

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Fri, Jan 04, 2013 at 05:55:18PM +0100, Johannes Sixt wrote: > Am 04.01.2013 13:47, schrieb Jeff King: > > I have two reservations with this patch: > > > > 1. We are ignoring SIGPIPE all the time. For an alias that is calling > > "log", that is fine. But if pack-objects dies on the serve

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Jeff King writes: > I have two reservations with this patch: > > 1. We are ignoring SIGPIPE all the time. For an alias that is calling > "log", that is fine. But if pack-objects dies on the server side, > seeing that it died from SIGPIPE is useful data, and we are > squelching th

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Fri, Jan 04, 2013 at 02:20:52PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I have two reservations with this patch: > > > > 1. We are ignoring SIGPIPE all the time. For an alias that is calling > > "log", that is fine. But if pack-objects dies on the server side, > > s

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Jeff King writes: > When git executes an alias that specifies an external > command, it will complain if the alias dies due to a signal. > This is usually a good thing, as signal deaths are > unexpected. However, SIGPIPE is not unexpected for many > commands which produce a lot of output; it is i

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Wed, Jan 09, 2013 at 12:48:20PM -0800, Junio C Hamano wrote: > > $ git lg -p > > [user hits 'q' to exit pager] > > error: git lgbase --more-options died of signal 13 > > fatal: While expanding alias 'lg': 'git lgbase --more-options': Success > > > > Many users won't see this, because we

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Jeff King writes: > But we still say "error: ... died of signal 13", because that comes from > inside wait_or_whine. So it is a separate issue whether or not > wait_or_whine should be silent on SIGPIPE (we already are on SIGINT and > SIGQUIT, as of some recent patches). > > The upside is that it

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Junio C Hamano wrote: > Jeff King writes: >> But we still say "error: ... died of signal 13", because that comes from >> inside wait_or_whine. So it is a separate issue whether or not >> wait_or_whine should be silent on SIGPIPE (we already are on SIGINT and >> SIGQUIT, as of some recent patches)

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Jonathan Nieder writes: > I'm not sure whether there are SIGPIPE instances we really don't want > to be silent about, though. I suspect not. ;-) > > Compare , >

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Wed, Jan 09, 2013 at 01:49:41PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > But we still say "error: ... died of signal 13", because that comes from > > inside wait_or_whine. So it is a separate issue whether or not > > wait_or_whine should be silent on SIGPIPE (we already are on S

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Wed, Jan 09, 2013 at 04:18:44PM -0800, Jonathan Nieder wrote: > > Do we know if we are upstream of a pager that reads from us through > > a pipe (I think we should, especially in a case where we are the one > > who processed the "git -p $alias" option)? Is there any other case > > where we wou

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Jeff King writes: > Maybe the right rule is "if we are using the shell to execute, do not > mention SIGPIPE"? It seems a little iffy at first, but: > > 1. It tends to coincide with direct use of internal tools versus > external tools. > > 2. We do not reliably get SIGPIPE there, anyway,

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

On Thu, Jan 10, 2013 at 12:22:49PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Maybe the right rule is "if we are using the shell to execute, do not > > mention SIGPIPE"? It seems a little iffy at first, but: > > > > 1. It tends to coincide with direct use of internal tools versus >

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Am 10.01.2013 21:22, schrieb Junio C Hamano: > Jeff King writes: > >> Maybe the right rule is "if we are using the shell to execute, do not >> mention SIGPIPE"? It seems a little iffy at first, but: >> >> 1. It tends to coincide with direct use of internal tools versus >> external tools. >

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

Johannes Sixt writes: > The interesting cases are when git reads back the output of the command. > Here, a SIGPIPE death of the child would indicate a bug in git, I think, > and some diagnostic would be worth it. But we can just as well declare > that git doesn't have bugs ;) > > These are the in

Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

How? Thanks. code 128 <http://www.keepdynamic.com/barcoding/asp-net-barcode-generator.shtml> -- View this message in context: http://git.661346.n2.nabble.com/RFC-PATCH-avoid-SIGPIPE-warnings-for-aliases-tp7574160p7615524.html Sent from the git mailing list archive at Nabble.com. -- To