2005-07-31 21:17:43 +02:00
|
|
|
#include "cache.h"
|
|
|
|
#include "run-command.h"
|
2006-01-11 03:12:17 +01:00
|
|
|
#include "exec_cmd.h"
|
2005-07-31 21:17:43 +02:00
|
|
|
|
2007-03-12 19:37:28 +01:00
|
|
|
static inline void close_pair(int fd[2])
|
|
|
|
{
|
|
|
|
close(fd[0]);
|
|
|
|
close(fd[1]);
|
|
|
|
}
|
|
|
|
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 21:12:18 +01:00
|
|
|
#ifndef WIN32
|
2007-03-12 19:37:55 +01:00
|
|
|
static inline void dup_devnull(int to)
|
|
|
|
{
|
|
|
|
int fd = open("/dev/null", O_RDWR);
|
|
|
|
dup2(fd, to);
|
|
|
|
close(fd);
|
|
|
|
}
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 21:12:18 +01:00
|
|
|
#endif
|
2007-03-12 19:37:55 +01:00
|
|
|
|
2009-12-30 11:53:16 +01:00
|
|
|
static const char **prepare_shell_cmd(const char **argv)
|
|
|
|
{
|
|
|
|
int argc, nargc = 0;
|
|
|
|
const char **nargv;
|
|
|
|
|
|
|
|
for (argc = 0; argv[argc]; argc++)
|
|
|
|
; /* just counting */
|
|
|
|
/* +1 for NULL, +3 for "sh -c" plus extra $0 */
|
|
|
|
nargv = xmalloc(sizeof(*nargv) * (argc + 1 + 3));
|
|
|
|
|
|
|
|
if (argc < 1)
|
|
|
|
die("BUG: shell command is empty");
|
|
|
|
|
2009-12-30 11:55:36 +01:00
|
|
|
if (strcspn(argv[0], "|&;<>()$`\\\"' \t\n*?[#~=%") != strlen(argv[0])) {
|
|
|
|
nargv[nargc++] = "sh";
|
|
|
|
nargv[nargc++] = "-c";
|
2009-12-30 11:53:16 +01:00
|
|
|
|
2009-12-30 11:55:36 +01:00
|
|
|
if (argc < 2)
|
|
|
|
nargv[nargc++] = argv[0];
|
|
|
|
else {
|
|
|
|
struct strbuf arg0 = STRBUF_INIT;
|
|
|
|
strbuf_addf(&arg0, "%s \"$@\"", argv[0]);
|
|
|
|
nargv[nargc++] = strbuf_detach(&arg0, NULL);
|
|
|
|
}
|
2009-12-30 11:53:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
for (argc = 0; argv[argc]; argc++)
|
|
|
|
nargv[nargc++] = argv[argc];
|
|
|
|
nargv[nargc] = NULL;
|
|
|
|
|
|
|
|
return nargv;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef WIN32
|
|
|
|
static int execv_shell_cmd(const char **argv)
|
|
|
|
{
|
|
|
|
const char **nargv = prepare_shell_cmd(argv);
|
|
|
|
trace_argv_printf(nargv, "trace: exec:");
|
|
|
|
execvp(nargv[0], (char **)nargv);
|
|
|
|
free(nargv);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-01-10 14:07:52 +01:00
|
|
|
#ifndef WIN32
|
|
|
|
static int child_err = 2;
|
2010-01-10 14:11:22 +01:00
|
|
|
static int child_notifier = -1;
|
|
|
|
|
|
|
|
static void notify_parent(void)
|
|
|
|
{
|
|
|
|
write(child_notifier, "", 1);
|
|
|
|
}
|
2010-01-10 14:07:52 +01:00
|
|
|
|
|
|
|
static NORETURN void die_child(const char *err, va_list params)
|
|
|
|
{
|
|
|
|
char msg[4096];
|
|
|
|
int len = vsnprintf(msg, sizeof(msg), err, params);
|
|
|
|
if (len > sizeof(msg))
|
|
|
|
len = sizeof(msg);
|
|
|
|
|
|
|
|
write(child_err, "fatal: ", 7);
|
|
|
|
write(child_err, msg, len);
|
|
|
|
write(child_err, "\n", 1);
|
|
|
|
exit(128);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void set_cloexec(int fd)
|
|
|
|
{
|
|
|
|
int flags = fcntl(fd, F_GETFD);
|
|
|
|
if (flags >= 0)
|
|
|
|
fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2010-01-10 14:08:45 +01:00
|
|
|
static int wait_or_whine(pid_t pid, const char *argv0, int silent_exec_failure)
|
|
|
|
{
|
|
|
|
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)) {
|
|
|
|
code = WTERMSIG(status);
|
|
|
|
error("%s died of signal %d", argv0, code);
|
|
|
|
/*
|
|
|
|
* This return value is chosen so that code & 0xff
|
|
|
|
* mimics the exit code that a POSIX shell would report for
|
|
|
|
* a program that died from this signal.
|
|
|
|
*/
|
|
|
|
code -= 128;
|
|
|
|
} else if (WIFEXITED(status)) {
|
|
|
|
code = WEXITSTATUS(status);
|
|
|
|
/*
|
|
|
|
* Convert special exit code when execvp failed.
|
|
|
|
*/
|
|
|
|
if (code == 127) {
|
|
|
|
code = -1;
|
|
|
|
failed_errno = ENOENT;
|
|
|
|
if (!silent_exec_failure)
|
|
|
|
error("cannot run %s: %s", argv0,
|
|
|
|
strerror(ENOENT));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
error("waitpid is confused (%s)", argv0);
|
|
|
|
}
|
|
|
|
errno = failed_errno;
|
|
|
|
return code;
|
|
|
|
}
|
|
|
|
|
2007-03-10 09:28:05 +01:00
|
|
|
int start_command(struct child_process *cmd)
|
2005-07-31 21:17:43 +02:00
|
|
|
{
|
2007-10-19 21:47:58 +02:00
|
|
|
int need_in, need_out, need_err;
|
|
|
|
int fdin[2], fdout[2], fderr[2];
|
2009-08-04 11:28:40 +02:00
|
|
|
int failed_errno = failed_errno;
|
2007-03-10 09:28:08 +01:00
|
|
|
|
2008-02-21 23:42:56 +01:00
|
|
|
/*
|
|
|
|
* In case of errors we must keep the promise to close FDs
|
|
|
|
* that have been passed in via ->in and ->out.
|
|
|
|
*/
|
|
|
|
|
2007-03-12 19:37:55 +01:00
|
|
|
need_in = !cmd->no_stdin && cmd->in < 0;
|
2007-03-10 09:28:08 +01:00
|
|
|
if (need_in) {
|
2008-02-21 23:42:56 +01: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-04 21:26:40 +02:00
|
|
|
failed_errno = errno;
|
2008-02-21 23:42:56 +01: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-04 21:26:40 +02:00
|
|
|
goto fail_pipe;
|
2008-02-21 23:42:56 +01:00
|
|
|
}
|
2007-03-10 09:28:08 +01:00
|
|
|
cmd->in = fdin[1];
|
|
|
|
}
|
|
|
|
|
2007-03-12 19:37:55 +01:00
|
|
|
need_out = !cmd->no_stdout
|
|
|
|
&& !cmd->stdout_to_stderr
|
|
|
|
&& cmd->out < 0;
|
2007-03-12 19:37:45 +01: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-04 21:26:40 +02:00
|
|
|
failed_errno = errno;
|
2007-03-12 19:37:45 +01:00
|
|
|
if (need_in)
|
|
|
|
close_pair(fdin);
|
2008-02-21 23:42:56 +01: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-04 21:26:40 +02:00
|
|
|
goto fail_pipe;
|
2007-03-12 19:37:45 +01:00
|
|
|
}
|
|
|
|
cmd->out = fdout[0];
|
|
|
|
}
|
|
|
|
|
2007-11-11 08:29:37 +01:00
|
|
|
need_err = !cmd->no_stderr && cmd->err < 0;
|
2007-10-19 21:47:58 +02: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-04 21:26:40 +02:00
|
|
|
failed_errno = errno;
|
2007-10-19 21:47:58 +02:00
|
|
|
if (need_in)
|
|
|
|
close_pair(fdin);
|
2008-02-21 23:42:56 +01:00
|
|
|
else if (cmd->in)
|
|
|
|
close(cmd->in);
|
2007-10-19 21:47:58 +02:00
|
|
|
if (need_out)
|
|
|
|
close_pair(fdout);
|
2008-02-21 23:42:56 +01: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-04 21:26:40 +02:00
|
|
|
fail_pipe:
|
|
|
|
error("cannot create pipe for %s: %s",
|
|
|
|
cmd->argv[0], strerror(failed_errno));
|
|
|
|
errno = failed_errno;
|
|
|
|
return -1;
|
2007-10-19 21:47:58 +02:00
|
|
|
}
|
|
|
|
cmd->err = fderr[0];
|
|
|
|
}
|
|
|
|
|
2008-07-07 15:41:34 +02:00
|
|
|
trace_argv_printf(cmd->argv, "trace: run_command:");
|
|
|
|
|
2009-09-16 10:20:22 +02:00
|
|
|
#ifndef WIN32
|
2010-01-10 14:11:22 +01:00
|
|
|
{
|
|
|
|
int notify_pipe[2];
|
|
|
|
if (pipe(notify_pipe))
|
|
|
|
notify_pipe[0] = notify_pipe[1] = -1;
|
|
|
|
|
2008-08-04 12:18:40 +02:00
|
|
|
fflush(NULL);
|
2007-03-10 09:28:05 +01:00
|
|
|
cmd->pid = fork();
|
|
|
|
if (!cmd->pid) {
|
2010-01-10 14:07:52 +01:00
|
|
|
/*
|
|
|
|
* Redirect the channel to write syscall error messages to
|
|
|
|
* before redirecting the process's stderr so that all die()
|
|
|
|
* in subsequent call paths use the parent's stderr.
|
|
|
|
*/
|
|
|
|
if (cmd->no_stderr || need_err) {
|
|
|
|
child_err = dup(2);
|
|
|
|
set_cloexec(child_err);
|
|
|
|
}
|
|
|
|
set_die_routine(die_child);
|
|
|
|
|
2010-01-10 14:11:22 +01:00
|
|
|
close(notify_pipe[0]);
|
|
|
|
set_cloexec(notify_pipe[1]);
|
|
|
|
child_notifier = notify_pipe[1];
|
|
|
|
atexit(notify_parent);
|
|
|
|
|
2007-03-12 19:37:55 +01:00
|
|
|
if (cmd->no_stdin)
|
|
|
|
dup_devnull(0);
|
|
|
|
else if (need_in) {
|
2007-03-10 09:28:08 +01:00
|
|
|
dup2(fdin[0], 0);
|
2007-03-12 19:37:28 +01:00
|
|
|
close_pair(fdin);
|
2007-03-10 09:28:08 +01:00
|
|
|
} else if (cmd->in) {
|
|
|
|
dup2(cmd->in, 0);
|
|
|
|
close(cmd->in);
|
2006-12-31 03:55:22 +01:00
|
|
|
}
|
2007-03-10 09:28:08 +01:00
|
|
|
|
2008-03-05 08:35:16 +01:00
|
|
|
if (cmd->no_stderr)
|
|
|
|
dup_devnull(2);
|
|
|
|
else if (need_err) {
|
|
|
|
dup2(fderr[1], 2);
|
|
|
|
close_pair(fderr);
|
|
|
|
}
|
|
|
|
|
2007-03-12 19:37:55 +01:00
|
|
|
if (cmd->no_stdout)
|
|
|
|
dup_devnull(1);
|
|
|
|
else if (cmd->stdout_to_stderr)
|
2006-12-31 03:55:19 +01:00
|
|
|
dup2(2, 1);
|
2007-03-12 19:37:45 +01: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-22 23:48:23 +02:00
|
|
|
if (cmd->dir && chdir(cmd->dir))
|
2009-06-27 17:58:46 +02:00
|
|
|
die_errno("exec '%s': cd to '%s' failed", cmd->argv[0],
|
|
|
|
cmd->dir);
|
2007-05-22 23:48:47 +02:00
|
|
|
if (cmd->env) {
|
2007-05-23 22:21:39 +02:00
|
|
|
for (; *cmd->env; cmd->env++) {
|
|
|
|
if (strchr(*cmd->env, '='))
|
2009-05-01 11:06:36 +02:00
|
|
|
putenv((char *)*cmd->env);
|
2007-05-23 22:21:39 +02:00
|
|
|
else
|
|
|
|
unsetenv(*cmd->env);
|
|
|
|
}
|
2007-05-22 23:48:47 +02:00
|
|
|
}
|
2010-01-10 14:11:22 +01:00
|
|
|
if (cmd->preexec_cb) {
|
|
|
|
/*
|
|
|
|
* We cannot predict what the pre-exec callback does.
|
|
|
|
* Forgo parent notification.
|
|
|
|
*/
|
|
|
|
close(child_notifier);
|
|
|
|
child_notifier = -1;
|
|
|
|
|
2008-07-22 09:12:46 +02:00
|
|
|
cmd->preexec_cb();
|
2010-01-10 14:11:22 +01:00
|
|
|
}
|
2007-03-10 09:28:00 +01:00
|
|
|
if (cmd->git_cmd) {
|
|
|
|
execv_git_cmd(cmd->argv);
|
2009-12-30 11:53:16 +01:00
|
|
|
} else if (cmd->use_shell) {
|
|
|
|
execv_shell_cmd(cmd->argv);
|
2006-01-11 03:12:17 +01:00
|
|
|
} else {
|
2007-03-10 09:28:00 +01:00
|
|
|
execvp(cmd->argv[0], (char *const*) cmd->argv);
|
2005-12-08 03:04:38 +01:00
|
|
|
}
|
2010-01-10 14:07:52 +01:00
|
|
|
/*
|
|
|
|
* Do not check for cmd->silent_exec_failure; the parent
|
|
|
|
* process will check it when it sees this exit code.
|
|
|
|
*/
|
|
|
|
if (errno == ENOENT)
|
|
|
|
exit(127);
|
|
|
|
else
|
|
|
|
die_errno("cannot exec '%s'", cmd->argv[0]);
|
2005-07-31 21:17:43 +02: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-04 21:26:40 +02:00
|
|
|
if (cmd->pid < 0)
|
|
|
|
error("cannot fork() for %s: %s", cmd->argv[0],
|
|
|
|
strerror(failed_errno = errno));
|
2010-01-10 14:11:22 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for child's execvp. If the execvp succeeds (or if fork()
|
|
|
|
* failed), EOF is seen immediately by the parent. Otherwise, the
|
|
|
|
* child process sends a single byte.
|
|
|
|
* Note that use of this infrastructure is completely advisory,
|
|
|
|
* therefore, we keep error checks minimal.
|
|
|
|
*/
|
|
|
|
close(notify_pipe[1]);
|
|
|
|
if (read(notify_pipe[0], ¬ify_pipe[1], 1) == 1) {
|
|
|
|
/*
|
|
|
|
* At this point we know that fork() succeeded, but execvp()
|
|
|
|
* failed. Errors have been reported to our stderr.
|
|
|
|
*/
|
|
|
|
wait_or_whine(cmd->pid, cmd->argv[0],
|
|
|
|
cmd->silent_exec_failure);
|
|
|
|
failed_errno = errno;
|
|
|
|
cmd->pid = -1;
|
|
|
|
}
|
|
|
|
close(notify_pipe[0]);
|
|
|
|
}
|
2007-12-07 22:08:59 +01:00
|
|
|
#else
|
2009-09-16 10:20:17 +02:00
|
|
|
{
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 21:12:18 +01:00
|
|
|
int fhin = 0, fhout = 1, fherr = 2;
|
2008-07-28 07:50:28 +02:00
|
|
|
const char **sargv = cmd->argv;
|
2007-12-07 22:08:59 +01:00
|
|
|
char **env = environ;
|
|
|
|
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 21:12:18 +01:00
|
|
|
if (cmd->no_stdin)
|
|
|
|
fhin = open("/dev/null", O_RDWR);
|
|
|
|
else if (need_in)
|
|
|
|
fhin = dup(fdin[0]);
|
|
|
|
else if (cmd->in)
|
|
|
|
fhin = dup(cmd->in);
|
|
|
|
|
|
|
|
if (cmd->no_stderr)
|
|
|
|
fherr = open("/dev/null", O_RDWR);
|
|
|
|
else if (need_err)
|
|
|
|
fherr = dup(fderr[1]);
|
|
|
|
|
|
|
|
if (cmd->no_stdout)
|
|
|
|
fhout = open("/dev/null", O_RDWR);
|
|
|
|
else if (cmd->stdout_to_stderr)
|
|
|
|
fhout = dup(fherr);
|
|
|
|
else if (need_out)
|
|
|
|
fhout = dup(fdout[1]);
|
|
|
|
else if (cmd->out > 1)
|
|
|
|
fhout = dup(cmd->out);
|
2007-12-07 22:08:59 +01:00
|
|
|
|
|
|
|
if (cmd->dir)
|
|
|
|
die("chdir in start_command() not implemented");
|
2009-09-11 19:40:08 +02:00
|
|
|
if (cmd->env)
|
|
|
|
env = make_augmented_environ(cmd->env);
|
2007-12-07 22:08:59 +01:00
|
|
|
|
|
|
|
if (cmd->git_cmd) {
|
2008-07-28 07:50:28 +02:00
|
|
|
cmd->argv = prepare_git_cmd(cmd->argv);
|
2009-12-30 11:53:16 +01:00
|
|
|
} else if (cmd->use_shell) {
|
|
|
|
cmd->argv = prepare_shell_cmd(cmd->argv);
|
2007-12-07 22:08:59 +01:00
|
|
|
}
|
|
|
|
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 21:12:18 +01:00
|
|
|
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env,
|
|
|
|
fhin, fhout, fherr);
|
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-04 21:26:40 +02:00
|
|
|
failed_errno = errno;
|
2009-07-04 21:26:42 +02:00
|
|
|
if (cmd->pid < 0 && (!cmd->silent_exec_failure || errno != ENOENT))
|
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-04 21:26:40 +02:00
|
|
|
error("cannot spawn %s: %s", cmd->argv[0], strerror(errno));
|
2007-12-07 22:08:59 +01:00
|
|
|
|
|
|
|
if (cmd->env)
|
|
|
|
free_environ(env);
|
|
|
|
if (cmd->git_cmd)
|
2008-07-28 07:50:28 +02:00
|
|
|
free(cmd->argv);
|
2007-12-07 22:08:59 +01:00
|
|
|
|
2008-07-28 07:50:28 +02:00
|
|
|
cmd->argv = sargv;
|
Windows: avoid the "dup dance" when spawning a child process
When stdin, stdout, or stderr must be redirected for a child process that
on Windows is spawned using one of the spawn() functions of Microsoft's
C runtime, then there is no choice other than to
1. make a backup copy of fd 0,1,2 with dup
2. dup2 the redirection source fd into 0,1,2
3. spawn
4. dup2 the backup back into 0,1,2
5. close the backup copy and the redirection source
We used this idiom as well -- but we are not using the spawn() functions
anymore!
Instead, we have our own implementation. We had hardcoded that stdin,
stdout, and stderr of the child process were inherited from the parent's
fds 0, 1, and 2. But we can actually specify any fd.
With this patch, the fds to inherit are passed from start_command()'s
WIN32 section to our spawn implementation. This way, we can avoid the
backup copies of the fds.
The backup copies were a bug waiting to surface: The OS handles underlying
the dup()ed fds were inherited by the child process (but were not
associated with a file descriptor in the child). Consequently, the file or
pipe represented by the OS handle remained open even after the backup copy
was closed in the parent process until the child exited.
Since our implementation of pipe() creates non-inheritable OS handles, we
still dup() file descriptors in start_command() because dup() happens to
create inheritable duplicates. (A nice side effect is that the fd cleanup
in start_command is the same for Windows and Unix and remains unchanged.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-15 21:12:18 +01:00
|
|
|
if (fhin != 0)
|
|
|
|
close(fhin);
|
|
|
|
if (fhout != 1)
|
|
|
|
close(fhout);
|
|
|
|
if (fherr != 2)
|
|
|
|
close(fherr);
|
2009-09-16 10:20:17 +02:00
|
|
|
}
|
2007-12-07 22:08:59 +01:00
|
|
|
#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-04 21:26:40 +02:00
|
|
|
errno = failed_errno;
|
|
|
|
return -1;
|
2007-12-07 22:08:59 +01:00
|
|
|
}
|
2007-03-10 09:28:08 +01:00
|
|
|
|
|
|
|
if (need_in)
|
|
|
|
close(fdin[0]);
|
|
|
|
else if (cmd->in)
|
|
|
|
close(cmd->in);
|
|
|
|
|
2007-03-12 19:37:45 +01:00
|
|
|
if (need_out)
|
|
|
|
close(fdout[1]);
|
2008-02-21 23:42:56 +01:00
|
|
|
else if (cmd->out)
|
2007-03-12 19:37:45 +01:00
|
|
|
close(cmd->out);
|
|
|
|
|
2007-10-19 21:47:58 +02:00
|
|
|
if (need_err)
|
|
|
|
close(fderr[1]);
|
|
|
|
|
2007-03-10 09:28:05 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2007-10-19 21:48:00 +02:00
|
|
|
int finish_command(struct child_process *cmd)
|
|
|
|
{
|
2009-07-04 21:26:42 +02:00
|
|
|
return wait_or_whine(cmd->pid, cmd->argv[0], cmd->silent_exec_failure);
|
2007-10-19 21:48:00 +02:00
|
|
|
}
|
|
|
|
|
2007-03-10 09:28:05 +01:00
|
|
|
int run_command(struct child_process *cmd)
|
|
|
|
{
|
|
|
|
int code = start_command(cmd);
|
|
|
|
if (code)
|
|
|
|
return code;
|
|
|
|
return finish_command(cmd);
|
|
|
|
}
|
|
|
|
|
2007-05-22 23:48:23 +02:00
|
|
|
static void prepare_run_command_v_opt(struct child_process *cmd,
|
2007-05-22 23:48:47 +02:00
|
|
|
const char **argv,
|
|
|
|
int opt)
|
2007-05-22 23:48:23 +02: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;
|
2009-07-04 21:26:42 +02:00
|
|
|
cmd->silent_exec_failure = opt & RUN_SILENT_EXEC_FAILURE ? 1 : 0;
|
2009-12-30 11:53:16 +01:00
|
|
|
cmd->use_shell = opt & RUN_USING_SHELL ? 1 : 0;
|
2007-05-22 23:48:23 +02:00
|
|
|
}
|
|
|
|
|
2007-03-10 09:28:00 +01:00
|
|
|
int run_command_v_opt(const char **argv, int opt)
|
|
|
|
{
|
|
|
|
struct child_process cmd;
|
2007-05-22 23:48:23 +02:00
|
|
|
prepare_run_command_v_opt(&cmd, argv, opt);
|
|
|
|
return run_command(&cmd);
|
|
|
|
}
|
|
|
|
|
2007-05-22 23:48:47 +02: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-19 21:48:00 +02:00
|
|
|
|
2009-09-16 10:20:22 +02:00
|
|
|
#ifdef WIN32
|
2009-09-16 10:20:21 +02:00
|
|
|
static unsigned __stdcall run_thread(void *data)
|
2007-12-08 22:19:14 +01:00
|
|
|
{
|
|
|
|
struct async *async = data;
|
|
|
|
return async->proc(async->fd_for_proc, async->data);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2007-10-19 21:48:00 +02: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-08 22:19:14 +01:00
|
|
|
async->out = pipe_out[0];
|
2007-10-19 21:48:00 +02:00
|
|
|
|
2009-09-16 10:20:22 +02:00
|
|
|
#ifndef WIN32
|
2008-08-04 02:30:03 +02:00
|
|
|
/* Flush stdio before fork() to avoid cloning buffers */
|
|
|
|
fflush(NULL);
|
|
|
|
|
2007-10-19 21:48:00 +02: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-08 22:19:14 +01: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-19 21:48:00 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int finish_async(struct async *async)
|
|
|
|
{
|
2009-09-16 10:20:22 +02:00
|
|
|
#ifndef WIN32
|
2009-07-04 21:26:42 +02:00
|
|
|
int ret = wait_or_whine(async->pid, "child process", 0);
|
2007-12-08 22:19:14 +01: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-19 21:48:00 +02:00
|
|
|
return ret;
|
|
|
|
}
|
2009-01-16 20:09:59 +01:00
|
|
|
|
|
|
|
int run_hook(const char *index_file, const char *name, ...)
|
|
|
|
{
|
|
|
|
struct child_process hook;
|
2009-01-17 04:02:55 +01:00
|
|
|
const char **argv = NULL, *env[2];
|
2009-01-16 20:09:59 +01:00
|
|
|
char index[PATH_MAX];
|
|
|
|
va_list args;
|
|
|
|
int ret;
|
2009-01-17 04:02:55 +01:00
|
|
|
size_t i = 0, alloc = 0;
|
2009-01-16 20:09:59 +01:00
|
|
|
|
2009-01-16 20:10:01 +01:00
|
|
|
if (access(git_path("hooks/%s", name), X_OK) < 0)
|
|
|
|
return 0;
|
|
|
|
|
2009-01-16 20:09:59 +01:00
|
|
|
va_start(args, name);
|
2009-01-17 04:02:55 +01: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-16 20:09:59 +01: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-04 21:26:40 +02:00
|
|
|
ret = run_command(&hook);
|
2009-01-17 04:02:55 +01:00
|
|
|
free(argv);
|
2009-01-16 20:09:59 +01:00
|
|
|
return ret;
|
|
|
|
}
|