git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Funny: git -p submodule summary
Date: Fri, 9 Jan 2009 04:48:43 -0500	[thread overview]
Message-ID: <20090109094843.GA4056@coredump.intra.peff.net> (raw)
In-Reply-To: <20090109092250.GA1809@coredump.intra.peff.net>

On Fri, Jan 09, 2009 at 04:22:50AM -0500, Jeff King wrote:

> So I think to do things right, we have to be even more complicated. When
> we spawn the pager, we keep git as a single process. We register the
> atexit() handler to wait for the pager, and intercept any death signals
> to do the same. Then, if we are running a builtin, it is business as
> usual. But if we want to exec something, instead we have to actually
> spawn into the three-process form. Meaning we have to use run_command to
> start it, and then wait for it and the pager to return.

Actually, this turned out to be quite a small patch. It fixes the
problem you were seeing, and it should work on Windows. It incurs an
extra fork() for every dashed-external that we try.

There is a little noise in the patch, so let me highlight the three
things that are happening (a "real" patch should break this into three
patches in a series):

  1. The noise is from renaming the static run_command, which conflicts
     with the definition in run_command.h

  2. Substituting run_command for execvp.

  3. run_command needs to signal "I couldn't exec this" as opposed to
     other errors, since we care about the difference here. I do this
     here with exit(127), but probably we should recognize this in
     wait_or_whine and hand out the same error code for posix and mingw
     platforms.

As for the extra fork, we could do away with it if we scanned the path
looking for the external before just exec'ing it. I think this is better
in the long run anyway, because then we can do other setup specific to
running an external command (I don't remember the details, but I ran
afoul of this when I was doing pager stuff a while ago).

Patch is below.

---
diff --git a/git.c b/git.c
index ecc8fad..fa946b9 100644
--- a/git.c
+++ b/git.c
@@ -2,6 +2,7 @@
 #include "exec_cmd.h"
 #include "cache.h"
 #include "quote.h"
+#include "run-command.h"
 
 const char git_usage_string[] =
 	"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
@@ -219,7 +220,7 @@ struct cmd_struct {
 	int option;
 };
 
-static int run_command(struct cmd_struct *p, int argc, const char **argv)
+static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
 {
 	int status;
 	struct stat st;
@@ -384,7 +385,7 @@ static void handle_internal_command(int argc, const char **argv)
 		struct cmd_struct *p = commands+i;
 		if (strcmp(p->cmd, cmd))
 			continue;
-		exit(run_command(p, argc, argv));
+		exit(run_builtin(p, argc, argv));
 	}
 }
 
@@ -392,6 +393,7 @@ static void execv_dashed_external(const char **argv)
 {
 	struct strbuf cmd = STRBUF_INIT;
 	const char *tmp;
+	int status;
 
 	strbuf_addf(&cmd, "git-%s", argv[0]);
 
@@ -406,8 +408,13 @@ static void execv_dashed_external(const char **argv)
 
 	trace_argv_printf(argv, "trace: exec:");
 
-	/* execvp() can only ever return if it fails */
-	execvp(cmd.buf, (char **)argv);
+	/*
+	 * if we failed because the command was not found, it is
+	 * OK to return. Otherwise, we just pass along the status code.
+	 */
+	status = run_command_v_opt(argv, 0);
+	if (status != 127 && status != -ERR_RUN_COMMAND_FORK)
+		exit(-status);
 
 	trace_printf("trace: exec failed: %s\n", strerror(errno));
 
diff --git a/run-command.c b/run-command.c
index c90cdc5..539609e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -118,7 +118,7 @@ int start_command(struct child_process *cmd)
 		} else {
 			execvp(cmd->argv[0], (char *const*) cmd->argv);
 		}
-		die("exec %s failed.", cmd->argv[0]);
+		exit(127);
 	}
 #else
 	int s0 = -1, s1 = -1, s2 = -1;	/* backups of stdin, stdout, stderr */

  reply	other threads:[~2009-01-09  9:50 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 [this message]
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
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=20090109094843.GA4056@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).