git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joey Hess <joey@kitenet.net>
To: git@vger.kernel.org
Subject: git subcommand sigint gotcha
Date: Tue, 19 Oct 2010 00:53:00 -0400	[thread overview]
Message-ID: <20101019045300.GA18043@gnu.kitenet.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

I was trying to write a git subcommand, and I noticed that if I ctrl-c'd
it, git would return, but leave the subcommand running in the
background.

You can see the problem with this test case. 

#!/usr/bin/perl
print "first sleep...\n";
$ret=system("sleep", "1m");
print "second sleep...\n";
system("sleep", "1s");
print "done with second sleep\n";

If you put it in path named git-sleep, then run "git sleep" and press ctrl-c,
it keeps running:

joey@gnu:~>git sleep
first sleep...
^Csecond sleep...
joey@gnu:~>done with second sleep

So what's going on? Well, perl's system() blocks sigint while the child
process is running. So if you run this as git-sleep, and press ctrl-c,
it will continue on to the second sleep. If the code above checked the
return status of system() it could detect that it was killed by SIGINT
and itself exit.

What I don't understand is, why does git not wait() on the subcommand it
ran? Any subcommand that forgets to check exit codes is liable to exhibit
this weird behavior sometimes. 

Ie, imagine the subcommand was running something like 
"git config --get core.bare" instead of sleep. 
It'd be easy to forget to check the exit status of that for a SIGINT; if
the user ctrl-c'd at just the right instant, weird things would happen.

-- 
see shy jo

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

             reply	other threads:[~2010-10-19  5:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-19  4:53 Joey Hess [this message]
2010-10-19  9:55 ` git subcommand sigint gotcha Dmitry Potapov
2010-10-19 11:59   ` RFC: [PATCH] ignore SIGINT&QUIT while waiting for external command Dmitry Potapov
2010-10-19 13:32     ` Jeff King
2010-10-19 13:40       ` Jeff King
2010-10-19 19:16         ` Jonathan Nieder
2010-10-19 19:50           ` Jeff King
2010-10-19 21:06           ` Jakub Narebski
2010-10-19 21:07             ` Jonathan Nieder
2010-10-19 16:31       ` Dmitry Potapov

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=20101019045300.GA18043@gnu.kitenet.net \
    --to=joey@kitenet.net \
    --cc=git@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).