All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j.sixt@viscovery.net>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: Funny: git -p submodule summary
Date: Mon, 12 Jan 2009 13:00:05 +0100	[thread overview]
Message-ID: <496B30C5.2060207@viscovery.net> (raw)
In-Reply-To: <20090112112109.GA3825@coredump.intra.peff.net>

Jeff King schrieb:
> Hrm. How do you properly detect "killed by SIGINT" on Windows?

Good question. The exit code is 0xc000013a if the signal was generated by
hitting Ctrl-C (tested with 'git --no-pager log'), but it is 3 if the
signal was "generated" by 'raise(SIGINT)'. The implementation of the
latter just calls _exit(3) (same for other deadly signals). Wow!

>> -#define SIGKILL 0
>> -#define SIGCHLD 0
>> -#define SIGPIPE 0
>> -#define SIGHUP 0
>> -#define SIGQUIT 0
>> -#define SIGALRM 100
>> +#define SIGHUP 1
>> +#define SIGQUIT 3
>> +#define SIGKILL 9
>> +#define SIGPIPE 13
>> +#define SIGALRM 14
>> +#define SIGCHLD 17
> 
> Don't these get fed to signal()? Does Windows really not care about
> getting bogus numbers versus 0 (which is, admittedly, bogus itself)? Or
> are we just ignoring the return code everywhere?

Windows's signal() does return EINVAL; appearently, we never check the
return code. :-P

-- Hannes

  reply	other threads:[~2009-01-12 12:01 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-08 15:07 Funny: git -p submodule summary Johannes Schindelin
2009-01-08 15:30 ` Johannes Schindelin
2009-01-09  8:38 ` Jeff King
2009-01-09  9:22   ` Jeff King
2009-01-09  9:48     ` Jeff King
2009-01-09 10:09     ` Johannes Sixt
2009-01-09 10:13       ` Jeff King
2009-01-09 10:36         ` Johannes Sixt
2009-01-09 10:47           ` Jeff King
2009-01-11 11:22           ` Jeff King
2009-01-11 11:25             ` [PATCH 1/4] Makefile: clean up TEST_PROGRAMS definition Jeff King
2009-01-11 11:32             ` [PATCH 2/4] chain kill signals for cleanup functions Jeff King
2009-01-11 11:40               ` Jeff King
2009-01-11 11:36             ` [PATCH 3/4] refactor signal handling " Jeff King
2009-01-11 11:36             ` [PATCH 4/4] pager: do wait_for_pager on signal death Jeff King
2009-01-11 21:13               ` Junio C Hamano
2009-01-12 10:59             ` Funny: git -p submodule summary Johannes Sixt
2009-01-12 11:21               ` Jeff King
2009-01-12 12:00                 ` Johannes Sixt [this message]
2009-01-12 12:03                   ` Jeff King
2009-01-12 12:19                     ` Johannes Sixt
2009-01-09  9:30   ` Junio C Hamano
2009-01-09  9:33     ` Jeff King
2009-01-09  9:38       ` Junio C Hamano
2009-01-27  6:25 ` [RFC/PATCH 0/3] fix "Funny: git -p submodule summary" Jeff King
2009-01-27  6:26   ` [RFC/PATCH 1/3] git: s/run_command/run_builtin/ Jeff King
2009-01-27  6:27   ` [RFC/PATCH 2/3] run_command: handle missing command errors more gracefully Jeff King
2009-01-27  6:27   ` [RFC/PATCH 3/3] git: use run_command to execute dashed externals Jeff King
2009-01-27 10:06   ` [RFC/PATCH 0/3] fix "Funny: git -p submodule summary" Johannes Sixt
2009-01-27 12:23     ` Jeff King
2009-01-27 12:46       ` Johannes Sixt
2009-01-28  7:17         ` Jeff King
2009-01-27 16:31   ` Johannes Schindelin
2009-01-28  7:30     ` Jeff King
2009-01-28  7:33       ` [PATCHv2 1/4] git: s/run_command/run_builtin/ Jeff King
2009-01-28  7:35       ` [PATCHv2 2/4] run_command: handle missing command errors more gracefully Jeff King
2009-01-28  7:36       ` [PATCHv2 3/4] run-command: help callers distinguish errors Jeff King
2009-01-28  7:43         ` Jeff King
2009-01-28  7:47           ` Jeff King
2009-01-28  7:38       ` [PATCHv2 4/4] git: use run_command to execute dashed externals Jeff King
2009-01-28  7:54       ` [RFC/PATCH 0/3] fix "Funny: git -p submodule summary" Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=496B30C5.2060207@viscovery.net \
    --to=j.sixt@viscovery.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.