git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jan 10, 2013, 10:49 UTC
Message-ID
<20130110104930.GA21993@sigill.intra.peff.net>
In-Reply-To
<7vehhu3u2y.fsf@alter.siamese.dyndns.org>
On Wed, Jan 09, 2013 at 01:49:41PM -0800, Junio C Hamano wrote:
Show 18 quoted lines
> Jeff King <peff@peff.net> 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 is noise in this case that we would no longer see.
> > The downside is that we may be losing a clue when debugging server
> > problems, which do not expect to die from SIGPIPE.  Should it be an
> > optional run-command flag?
> 
> 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 would want to ignore child's death by SIGPIPE?  If the
> answers are yes and no, then perhaps we can ask pager_in_use() to
> decide this?

The answer to the first is unfortunately no. Consider an alias like "[alias]foo = !git log" (which yes, you could implement as just "log", but there are cases where you want to manipulate the environment and we do not allow it).

Your process tree for running "git foo" looks like:
  git foo               (A)
    git log             (B)
      less              (C)

The user hits 'q', which kills process C. Process B then dies due to SIGPIPE, and process A sees that the alias command died due to a signal. But process A has no clue that a pager is in effect; only process B, which spawned the pager, can know that. So A cannot see death-by-SIGPIPE and make a decision on whether a pager was in use.

If anything, it is process B's responsibility to say "Oops, I was killed by SIGPIPE. But that's OK, it's not a big deal to me". Which it could do by installing a SIGPIPE handler that just calls exit(0).

-Peff
Previous: Junio C HamanoNext: mimimimi
Message 22 of 23 in “avoid SIGPIPE warnings for aliases”
  1. avoid SIGPIPE warnings for aliasesJeff King, Jan 4, 2013
  2. Johannes SixtJan 4, 2013
  3. Jeff KingJan 4, 2013
  4. Junio C HamanoJan 4, 2013
  5. Jeff KingJan 5, 2013
  6. run-command: encode signal death as a positive integerJeff King, Jan 5, 2013
  7. Johannes SixtJan 5, 2013
  8. Jonathan NiederJan 5, 2013
  9. Jeff KingJan 5, 2013
  10. Jonathan NiederJan 5, 2013
  11. Junio C HamanoJan 6, 2013
  12. Junio C HamanoJan 9, 2013
  13. Jeff KingJan 9, 2013
  14. Junio C HamanoJan 9, 2013
  15. Jonathan NiederJan 10, 2013
  16. Junio C HamanoJan 10, 2013
  17. Jeff KingJan 10, 2013
  18. Junio C HamanoJan 10, 2013
  19. Jeff KingJan 10, 2013
  20. Johannes SixtJan 10, 2013
  21. Junio C HamanoJan 10, 2013
  22. Jeff KingJan 10, 2013
  23. mimimimiJul 21, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.