2005-08-01 03:17:43 +08:00
|
|
|
#include "cache.h"
|
|
|
|
#include "run-command.h"
|
2006-01-11 10:12:17 +08:00
|
|
|
#include "exec_cmd.h"
|
2005-08-01 03:17:43 +08:00
|
|
|
|
2007-03-13 02:37:28 +08:00
|
|
|
static inline void close_pair(int fd[2])
|
|
|
|
{
|
|
|
|
close(fd[0]);
|
|
|
|
close(fd[1]);
|
|
|
|
}
|
|
|
|
|
2007-03-13 02:37:55 +08:00
|
|
|
static inline void dup_devnull(int to)
|
|
|
|
{
|
|
|
|
int fd = open("/dev/null", O_RDWR);
|
|
|
|
dup2(fd, to);
|
|
|
|
close(fd);
|
|
|
|
}
|
|
|
|
|
2007-03-10 16:28:05 +08:00
|
|
|
int start_command(struct child_process *cmd)
|
2005-08-01 03:17:43 +08:00
|
|
|
{
|
2007-10-20 03:47:58 +08:00
|
|
|
int need_in, need_out, need_err;
|
|
|
|
int fdin[2], fdout[2], fderr[2];
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
int failed_errno;
|
2007-03-10 16:28:08 +08:00
|
|
|
|
2008-02-22 06:42:56 +08:00
|
|
|
/*
|
|
|
|
* In case of errors we must keep the promise to close FDs
|
|
|
|
* that have been passed in via ->in and ->out.
|
|
|
|
*/
|
|
|
|
|
2007-03-13 02:37:55 +08:00
|
|
|
need_in = !cmd->no_stdin && cmd->in < 0;
|
2007-03-10 16:28:08 +08:00
|
|
|
if (need_in) {
|
2008-02-22 06:42:56 +08:00
|
|
|
if (pipe(fdin) < 0) {
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
failed_errno = errno;
|
2008-02-22 06:42:56 +08:00
|
|
|
if (cmd->out > 0)
|
|
|
|
close(cmd->out);
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
goto fail_pipe;
|
2008-02-22 06:42:56 +08:00
|
|
|
}
|
2007-03-10 16:28:08 +08:00
|
|
|
cmd->in = fdin[1];
|
|
|
|
}
|
|
|
|
|
2007-03-13 02:37:55 +08:00
|
|
|
need_out = !cmd->no_stdout
|
|
|
|
&& !cmd->stdout_to_stderr
|
|
|
|
&& cmd->out < 0;
|
2007-03-13 02:37:45 +08:00
|
|
|
if (need_out) {
|
|
|
|
if (pipe(fdout) < 0) {
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
failed_errno = errno;
|
2007-03-13 02:37:45 +08:00
|
|
|
if (need_in)
|
|
|
|
close_pair(fdin);
|
2008-02-22 06:42:56 +08:00
|
|
|
else if (cmd->in)
|
|
|
|
close(cmd->in);
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
goto fail_pipe;
|
2007-03-13 02:37:45 +08:00
|
|
|
}
|
|
|
|
cmd->out = fdout[0];
|
|
|
|
}
|
|
|
|
|
2007-11-11 15:29:37 +08:00
|
|
|
need_err = !cmd->no_stderr && cmd->err < 0;
|
2007-10-20 03:47:58 +08:00
|
|
|
if (need_err) {
|
|
|
|
if (pipe(fderr) < 0) {
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
failed_errno = errno;
|
2007-10-20 03:47:58 +08:00
|
|
|
if (need_in)
|
|
|
|
close_pair(fdin);
|
2008-02-22 06:42:56 +08:00
|
|
|
else if (cmd->in)
|
|
|
|
close(cmd->in);
|
2007-10-20 03:47:58 +08:00
|
|
|
if (need_out)
|
|
|
|
close_pair(fdout);
|
2008-02-22 06:42:56 +08:00
|
|
|
else if (cmd->out)
|
|
|
|
close(cmd->out);
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
fail_pipe:
|
|
|
|
error("cannot create pipe for %s: %s",
|
|
|
|
cmd->argv[0], strerror(failed_errno));
|
|
|
|
errno = failed_errno;
|
|
|
|
return -1;
|
2007-10-20 03:47:58 +08:00
|
|
|
}
|
|
|
|
cmd->err = fderr[0];
|
|
|
|
}
|
|
|
|
|
2008-07-07 21:41:34 +08:00
|
|
|
trace_argv_printf(cmd->argv, "trace: run_command:");
|
|
|
|
|
2007-12-08 05:08:59 +08:00
|
|
|
#ifndef __MINGW32__
|
2008-08-04 18:18:40 +08:00
|
|
|
fflush(NULL);
|
2007-03-10 16:28:05 +08:00
|
|
|
cmd->pid = fork();
|
|
|
|
if (!cmd->pid) {
|
2007-03-13 02:37:55 +08:00
|
|
|
if (cmd->no_stdin)
|
|
|
|
dup_devnull(0);
|
|
|
|
else if (need_in) {
|
2007-03-10 16:28:08 +08:00
|
|
|
dup2(fdin[0], 0);
|
2007-03-13 02:37:28 +08:00
|
|
|
close_pair(fdin);
|
2007-03-10 16:28:08 +08:00
|
|
|
} else if (cmd->in) {
|
|
|
|
dup2(cmd->in, 0);
|
|
|
|
close(cmd->in);
|
2006-12-31 10:55:22 +08:00
|
|
|
}
|
2007-03-10 16:28:08 +08:00
|
|
|
|
2008-03-05 15:35:16 +08:00
|
|
|
if (cmd->no_stderr)
|
|
|
|
dup_devnull(2);
|
|
|
|
else if (need_err) {
|
|
|
|
dup2(fderr[1], 2);
|
|
|
|
close_pair(fderr);
|
|
|
|
}
|
|
|
|
|
2007-03-13 02:37:55 +08:00
|
|
|
if (cmd->no_stdout)
|
|
|
|
dup_devnull(1);
|
|
|
|
else if (cmd->stdout_to_stderr)
|
2006-12-31 10:55:19 +08:00
|
|
|
dup2(2, 1);
|
2007-03-13 02:37:45 +08:00
|
|
|
else if (need_out) {
|
|
|
|
dup2(fdout[1], 1);
|
|
|
|
close_pair(fdout);
|
|
|
|
} else if (cmd->out > 1) {
|
|
|
|
dup2(cmd->out, 1);
|
|
|
|
close(cmd->out);
|
|
|
|
}
|
|
|
|
|
2007-05-23 05:48:23 +08:00
|
|
|
if (cmd->dir && chdir(cmd->dir))
|
|
|
|
die("exec %s: cd to %s failed (%s)", cmd->argv[0],
|
|
|
|
cmd->dir, strerror(errno));
|
2007-05-23 05:48:47 +08:00
|
|
|
if (cmd->env) {
|
2007-05-24 04:21:39 +08:00
|
|
|
for (; *cmd->env; cmd->env++) {
|
|
|
|
if (strchr(*cmd->env, '='))
|
2009-05-01 17:06:36 +08:00
|
|
|
putenv((char *)*cmd->env);
|
2007-05-24 04:21:39 +08:00
|
|
|
else
|
|
|
|
unsetenv(*cmd->env);
|
|
|
|
}
|
2007-05-23 05:48:47 +08:00
|
|
|
}
|
2008-07-22 15:12:46 +08:00
|
|
|
if (cmd->preexec_cb)
|
|
|
|
cmd->preexec_cb();
|
2007-03-10 16:28:00 +08:00
|
|
|
if (cmd->git_cmd) {
|
|
|
|
execv_git_cmd(cmd->argv);
|
2006-01-11 10:12:17 +08:00
|
|
|
} else {
|
2007-03-10 16:28:00 +08:00
|
|
|
execvp(cmd->argv[0], (char *const*) cmd->argv);
|
2005-12-08 10:04:38 +08:00
|
|
|
}
|
run_command(): handle missing command errors more gracefully
When run_command() was asked to run a non-existant command, its behavior
varied depending on the platform:
- on POSIX systems, we would fork, and then after the execvp call
failed, we could call die(), which prints a message to stderr and
exits with code 128.
- on Windows, we do a PATH lookup, realize the program isn't there, and
then return ERR_RUN_COMMAND_FORK
The goal of this patch is to make it clear to callers that the specific
error was a missing command. To do this, we will return the error code
ERR_RUN_COMMAND_EXEC, which is already defined in run-command.h, checked
for in several places, but never actually gets set.
The new behavior is:
- on POSIX systems, we exit the forked process with code 127 (the same
as the shell uses to report missing commands). The parent process
recognizes this code and returns an EXEC error. The stderr message is
silenced, since the caller may be speculatively trying to run a
command. Instead, we use trace_printf so that somebody interested in
debugging can see the error that occured.
- on Windows, we check errno, which is already set correctly by
mingw_spawnvpe, and report an EXEC error instead of a FORK error
Thus it is safe to speculatively run a command:
int r = run_command_v_opt(argv, 0);
if (r == -ERR_RUN_COMMAND_EXEC)
/* oops, it wasn't found; try something else */
else
/* we failed for some other reason, error is in r */
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-28 15:35:33 +08:00
|
|
|
trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
|
|
|
|
strerror(errno));
|
|
|
|
exit(127);
|
2005-08-01 03:17:43 +08:00
|
|
|
}
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
if (cmd->pid < 0)
|
|
|
|
error("cannot fork() for %s: %s", cmd->argv[0],
|
|
|
|
strerror(failed_errno = errno));
|
2007-12-08 05:08:59 +08:00
|
|
|
#else
|
|
|
|
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
|
2008-07-28 13:50:28 +08:00
|
|
|
const char **sargv = cmd->argv;
|
2007-12-08 05:08:59 +08:00
|
|
|
char **env = environ;
|
|
|
|
|
|
|
|
if (cmd->no_stdin) {
|
|
|
|
s0 = dup(0);
|
|
|
|
dup_devnull(0);
|
|
|
|
} else if (need_in) {
|
|
|
|
s0 = dup(0);
|
|
|
|
dup2(fdin[0], 0);
|
|
|
|
} else if (cmd->in) {
|
|
|
|
s0 = dup(0);
|
|
|
|
dup2(cmd->in, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmd->no_stderr) {
|
|
|
|
s2 = dup(2);
|
|
|
|
dup_devnull(2);
|
|
|
|
} else if (need_err) {
|
|
|
|
s2 = dup(2);
|
|
|
|
dup2(fderr[1], 2);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmd->no_stdout) {
|
|
|
|
s1 = dup(1);
|
|
|
|
dup_devnull(1);
|
|
|
|
} else if (cmd->stdout_to_stderr) {
|
|
|
|
s1 = dup(1);
|
|
|
|
dup2(2, 1);
|
|
|
|
} else if (need_out) {
|
|
|
|
s1 = dup(1);
|
|
|
|
dup2(fdout[1], 1);
|
|
|
|
} else if (cmd->out > 1) {
|
|
|
|
s1 = dup(1);
|
|
|
|
dup2(cmd->out, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmd->dir)
|
|
|
|
die("chdir in start_command() not implemented");
|
|
|
|
if (cmd->env) {
|
|
|
|
env = copy_environ();
|
|
|
|
for (; *cmd->env; cmd->env++)
|
|
|
|
env = env_setenv(env, *cmd->env);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmd->git_cmd) {
|
2008-07-28 13:50:28 +08:00
|
|
|
cmd->argv = prepare_git_cmd(cmd->argv);
|
2007-12-08 05:08:59 +08:00
|
|
|
}
|
|
|
|
|
2007-11-25 05:49:16 +08:00
|
|
|
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
failed_errno = errno;
|
|
|
|
if (cmd->pid < 0 && errno != ENOENT)
|
|
|
|
error("cannot spawn %s: %s", cmd->argv[0], strerror(errno));
|
2007-12-08 05:08:59 +08:00
|
|
|
|
|
|
|
if (cmd->env)
|
|
|
|
free_environ(env);
|
|
|
|
if (cmd->git_cmd)
|
2008-07-28 13:50:28 +08:00
|
|
|
free(cmd->argv);
|
2007-12-08 05:08:59 +08:00
|
|
|
|
2008-07-28 13:50:28 +08:00
|
|
|
cmd->argv = sargv;
|
2007-12-08 05:08:59 +08:00
|
|
|
if (s0 >= 0)
|
|
|
|
dup2(s0, 0), close(s0);
|
|
|
|
if (s1 >= 0)
|
|
|
|
dup2(s1, 1), close(s1);
|
|
|
|
if (s2 >= 0)
|
|
|
|
dup2(s2, 2), close(s2);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
if (cmd->pid < 0) {
|
|
|
|
if (need_in)
|
|
|
|
close_pair(fdin);
|
|
|
|
else if (cmd->in)
|
|
|
|
close(cmd->in);
|
|
|
|
if (need_out)
|
|
|
|
close_pair(fdout);
|
|
|
|
else if (cmd->out)
|
|
|
|
close(cmd->out);
|
|
|
|
if (need_err)
|
|
|
|
close_pair(fderr);
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
errno = failed_errno;
|
|
|
|
return -1;
|
2007-12-08 05:08:59 +08:00
|
|
|
}
|
2007-03-10 16:28:08 +08:00
|
|
|
|
|
|
|
if (need_in)
|
|
|
|
close(fdin[0]);
|
|
|
|
else if (cmd->in)
|
|
|
|
close(cmd->in);
|
|
|
|
|
2007-03-13 02:37:45 +08:00
|
|
|
if (need_out)
|
|
|
|
close(fdout[1]);
|
2008-02-22 06:42:56 +08:00
|
|
|
else if (cmd->out)
|
2007-03-13 02:37:45 +08:00
|
|
|
close(cmd->out);
|
|
|
|
|
2007-10-20 03:47:58 +08:00
|
|
|
if (need_err)
|
|
|
|
close(fderr[1]);
|
|
|
|
|
2007-03-10 16:28:05 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
static int wait_or_whine(pid_t pid, const char *argv0)
|
2007-03-10 16:28:05 +08:00
|
|
|
{
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
int status, code = -1;
|
|
|
|
pid_t waiting;
|
|
|
|
int failed_errno = 0;
|
|
|
|
|
|
|
|
while ((waiting = waitpid(pid, &status, 0)) < 0 && errno == EINTR)
|
|
|
|
; /* nothing */
|
|
|
|
|
|
|
|
if (waiting < 0) {
|
|
|
|
failed_errno = errno;
|
|
|
|
error("waitpid for %s failed: %s", argv0, strerror(errno));
|
|
|
|
} else if (waiting != pid) {
|
|
|
|
error("waitpid is confused (%s)", argv0);
|
|
|
|
} else if (WIFSIGNALED(status)) {
|
|
|
|
error("%s died of signal", argv0);
|
|
|
|
} else if (WIFEXITED(status)) {
|
2005-08-01 03:17:43 +08:00
|
|
|
code = WEXITSTATUS(status);
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
/*
|
|
|
|
* Convert special exit code when execvp failed.
|
|
|
|
*/
|
|
|
|
if (code == 127) {
|
|
|
|
code = -1;
|
|
|
|
failed_errno = ENOENT;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
error("waitpid is confused (%s)", argv0);
|
2005-08-01 03:17:43 +08:00
|
|
|
}
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
errno = failed_errno;
|
|
|
|
return code;
|
2005-08-01 03:17:43 +08:00
|
|
|
}
|
2007-03-10 16:28:00 +08:00
|
|
|
|
2007-10-20 03:48:00 +08:00
|
|
|
int finish_command(struct child_process *cmd)
|
|
|
|
{
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
return wait_or_whine(cmd->pid, cmd->argv[0]);
|
2007-10-20 03:48:00 +08:00
|
|
|
}
|
|
|
|
|
2007-03-10 16:28:05 +08:00
|
|
|
int run_command(struct child_process *cmd)
|
|
|
|
{
|
|
|
|
int code = start_command(cmd);
|
|
|
|
if (code)
|
|
|
|
return code;
|
|
|
|
return finish_command(cmd);
|
|
|
|
}
|
|
|
|
|
2007-05-23 05:48:23 +08:00
|
|
|
static void prepare_run_command_v_opt(struct child_process *cmd,
|
2007-05-23 05:48:47 +08:00
|
|
|
const char **argv,
|
|
|
|
int opt)
|
2007-05-23 05:48:23 +08:00
|
|
|
{
|
|
|
|
memset(cmd, 0, sizeof(*cmd));
|
|
|
|
cmd->argv = argv;
|
|
|
|
cmd->no_stdin = opt & RUN_COMMAND_NO_STDIN ? 1 : 0;
|
|
|
|
cmd->git_cmd = opt & RUN_GIT_CMD ? 1 : 0;
|
|
|
|
cmd->stdout_to_stderr = opt & RUN_COMMAND_STDOUT_TO_STDERR ? 1 : 0;
|
|
|
|
}
|
|
|
|
|
2007-03-10 16:28:00 +08:00
|
|
|
int run_command_v_opt(const char **argv, int opt)
|
|
|
|
{
|
|
|
|
struct child_process cmd;
|
2007-05-23 05:48:23 +08:00
|
|
|
prepare_run_command_v_opt(&cmd, argv, opt);
|
|
|
|
return run_command(&cmd);
|
|
|
|
}
|
|
|
|
|
2007-05-23 05:48:47 +08:00
|
|
|
int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const char *const *env)
|
|
|
|
{
|
|
|
|
struct child_process cmd;
|
|
|
|
prepare_run_command_v_opt(&cmd, argv, opt);
|
|
|
|
cmd.dir = dir;
|
|
|
|
cmd.env = env;
|
|
|
|
return run_command(&cmd);
|
|
|
|
}
|
2007-10-20 03:48:00 +08:00
|
|
|
|
2007-12-09 05:19:14 +08:00
|
|
|
#ifdef __MINGW32__
|
|
|
|
static __stdcall unsigned run_thread(void *data)
|
|
|
|
{
|
|
|
|
struct async *async = data;
|
|
|
|
return async->proc(async->fd_for_proc, async->data);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2007-10-20 03:48:00 +08:00
|
|
|
int start_async(struct async *async)
|
|
|
|
{
|
|
|
|
int pipe_out[2];
|
|
|
|
|
|
|
|
if (pipe(pipe_out) < 0)
|
|
|
|
return error("cannot create pipe: %s", strerror(errno));
|
2007-12-09 05:19:14 +08:00
|
|
|
async->out = pipe_out[0];
|
2007-10-20 03:48:00 +08:00
|
|
|
|
2007-12-09 05:19:14 +08:00
|
|
|
#ifndef __MINGW32__
|
2008-08-04 08:30:03 +08:00
|
|
|
/* Flush stdio before fork() to avoid cloning buffers */
|
|
|
|
fflush(NULL);
|
|
|
|
|
2007-10-20 03:48:00 +08:00
|
|
|
async->pid = fork();
|
|
|
|
if (async->pid < 0) {
|
|
|
|
error("fork (async) failed: %s", strerror(errno));
|
|
|
|
close_pair(pipe_out);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (!async->pid) {
|
|
|
|
close(pipe_out[0]);
|
|
|
|
exit(!!async->proc(pipe_out[1], async->data));
|
|
|
|
}
|
|
|
|
close(pipe_out[1]);
|
2007-12-09 05:19:14 +08:00
|
|
|
#else
|
|
|
|
async->fd_for_proc = pipe_out[1];
|
|
|
|
async->tid = (HANDLE) _beginthreadex(NULL, 0, run_thread, async, 0, NULL);
|
|
|
|
if (!async->tid) {
|
|
|
|
error("cannot create thread: %s", strerror(errno));
|
|
|
|
close_pair(pipe_out);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
#endif
|
2007-10-20 03:48:00 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int finish_async(struct async *async)
|
|
|
|
{
|
2007-12-09 05:19:14 +08:00
|
|
|
#ifndef __MINGW32__
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
int ret = wait_or_whine(async->pid, "child process");
|
2007-12-09 05:19:14 +08:00
|
|
|
#else
|
|
|
|
DWORD ret = 0;
|
|
|
|
if (WaitForSingleObject(async->tid, INFINITE) != WAIT_OBJECT_0)
|
|
|
|
ret = error("waiting for thread failed: %lu", GetLastError());
|
|
|
|
else if (!GetExitCodeThread(async->tid, &ret))
|
|
|
|
ret = error("cannot get thread exit code: %lu", GetLastError());
|
|
|
|
CloseHandle(async->tid);
|
|
|
|
#endif
|
2007-10-20 03:48:00 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2009-01-17 03:09:59 +08:00
|
|
|
|
|
|
|
int run_hook(const char *index_file, const char *name, ...)
|
|
|
|
{
|
|
|
|
struct child_process hook;
|
2009-01-17 11:02:55 +08:00
|
|
|
const char **argv = NULL, *env[2];
|
2009-01-17 03:09:59 +08:00
|
|
|
char index[PATH_MAX];
|
|
|
|
va_list args;
|
|
|
|
int ret;
|
2009-01-17 11:02:55 +08:00
|
|
|
size_t i = 0, alloc = 0;
|
2009-01-17 03:09:59 +08:00
|
|
|
|
2009-01-17 03:10:01 +08:00
|
|
|
if (access(git_path("hooks/%s", name), X_OK) < 0)
|
|
|
|
return 0;
|
|
|
|
|
2009-01-17 03:09:59 +08:00
|
|
|
va_start(args, name);
|
2009-01-17 11:02:55 +08:00
|
|
|
ALLOC_GROW(argv, i + 1, alloc);
|
|
|
|
argv[i++] = git_path("hooks/%s", name);
|
|
|
|
while (argv[i-1]) {
|
|
|
|
ALLOC_GROW(argv, i + 1, alloc);
|
|
|
|
argv[i++] = va_arg(args, const char *);
|
|
|
|
}
|
2009-01-17 03:09:59 +08:00
|
|
|
va_end(args);
|
|
|
|
|
|
|
|
memset(&hook, 0, sizeof(hook));
|
|
|
|
hook.argv = argv;
|
|
|
|
hook.no_stdin = 1;
|
|
|
|
hook.stdout_to_stderr = 1;
|
|
|
|
if (index_file) {
|
|
|
|
snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
|
|
|
|
env[0] = index;
|
|
|
|
env[1] = NULL;
|
|
|
|
hook.env = env;
|
|
|
|
}
|
|
|
|
|
run_command: report system call errors instead of returning error codes
The motivation for this change is that system call failures are serious
errors that should be reported to the user, but only few callers took the
burden to decode the error codes that the functions returned into error
messages.
If at all, then only an unspecific error message was given. A prominent
example is this:
$ git upload-pack . | :
fatal: unable to run 'git-upload-pack'
In this example, git-upload-pack, the external command invoked through the
git wrapper, dies due to SIGPIPE, but the git wrapper does not bother to
report the real cause. In fact, this very error message is copied to the
syslog if git-daemon's client aborts the connection early.
With this change, system call failures are reported immediately after the
failure and only a generic failure code is returned to the caller. In the
above example the error is now to the point:
$ git upload-pack . | :
error: git-upload-pack died of signal
Note that there is no error report if the invoked program terminated with
a non-zero exit code, because it is reasonable to expect that the invoked
program has already reported an error. (But many run_command call sites
nevertheless write a generic error message.)
There was one special return code that was used to identify the case where
run_command failed because the requested program could not be exec'd. This
special case is now treated like a system call failure with errno set to
ENOENT. No error is reported in this case, because the call site in git.c
expects this as a normal result. Therefore, the callers that carefully
decoded the return value still check for this condition.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-05 03:26:40 +08:00
|
|
|
ret = run_command(&hook);
|
2009-01-17 11:02:55 +08:00
|
|
|
free(argv);
|
2009-01-17 03:09:59 +08:00
|
|
|
return ret;
|
|
|
|
}
|