git/exec_cmd.c

152 строки
3.0 KiB
C
Исходник Обычный вид История

#include "cache.h"
#include "exec_cmd.h"
#include "quote.h"
#include "argv-array.h"
#define MAX_ARGS 32
static const char *argv_exec_path;
static const char *argv0_path;
char *system_path(const char *path)
{
Compute prefix at runtime if RUNTIME_PREFIX is set This commit adds support for relocatable binaries (called RUNTIME_PREFIX). Such binaries can be moved together with the system configuration files to a different directory, as long as the relative paths from the binary to the configuration files is preserved. This functionality is essential on Windows where we deliver git binaries with an installer that allows to freely choose the installation location. If RUNTIME_PREFIX is unset we use the static prefix. This will be the default on Unix. Thus, the behavior on Unix will remain identical to the old implementation, which used to add the prefix in the Makefile. If RUNTIME_PREFIX is set the prefix is computed from the location of the executable. In this case, system_path() tries to strip known directories that executables can be located in from the path of the executable. If the path is successfully stripped it is used as the prefix. For example, if the executable is "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is "/msysgit". If the runtime prefix computation fails, we fall back to the static prefix specified in the makefile. This can be the case if the executable is not installed at a known location. Note that our test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global configuration files during testing. Hence testing does not trigger the fall back. Note that RUNTIME_PREFIX only works on Windows, though adding support on Unix should not be too hard. The implementation requires argv0_path to be set to an absolute path. argv0_path must point to the directory of the executable. We use assert() to verify this in debug builds. On Windows, the wrapper for main() (see compat/mingw.h) guarantees that argv0_path is correctly initialized. On Unix, further work is required before RUNTIME_PREFIX can be enabled. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 15:00:14 +03:00
#ifdef RUNTIME_PREFIX
static const char *prefix;
#else
static const char *prefix = PREFIX;
Compute prefix at runtime if RUNTIME_PREFIX is set This commit adds support for relocatable binaries (called RUNTIME_PREFIX). Such binaries can be moved together with the system configuration files to a different directory, as long as the relative paths from the binary to the configuration files is preserved. This functionality is essential on Windows where we deliver git binaries with an installer that allows to freely choose the installation location. If RUNTIME_PREFIX is unset we use the static prefix. This will be the default on Unix. Thus, the behavior on Unix will remain identical to the old implementation, which used to add the prefix in the Makefile. If RUNTIME_PREFIX is set the prefix is computed from the location of the executable. In this case, system_path() tries to strip known directories that executables can be located in from the path of the executable. If the path is successfully stripped it is used as the prefix. For example, if the executable is "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is "/msysgit". If the runtime prefix computation fails, we fall back to the static prefix specified in the makefile. This can be the case if the executable is not installed at a known location. Note that our test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global configuration files during testing. Hence testing does not trigger the fall back. Note that RUNTIME_PREFIX only works on Windows, though adding support on Unix should not be too hard. The implementation requires argv0_path to be set to an absolute path. argv0_path must point to the directory of the executable. We use assert() to verify this in debug builds. On Windows, the wrapper for main() (see compat/mingw.h) guarantees that argv0_path is correctly initialized. On Unix, further work is required before RUNTIME_PREFIX can be enabled. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 15:00:14 +03:00
#endif
struct strbuf d = STRBUF_INIT;
if (is_absolute_path(path))
return xstrdup(path);
Compute prefix at runtime if RUNTIME_PREFIX is set This commit adds support for relocatable binaries (called RUNTIME_PREFIX). Such binaries can be moved together with the system configuration files to a different directory, as long as the relative paths from the binary to the configuration files is preserved. This functionality is essential on Windows where we deliver git binaries with an installer that allows to freely choose the installation location. If RUNTIME_PREFIX is unset we use the static prefix. This will be the default on Unix. Thus, the behavior on Unix will remain identical to the old implementation, which used to add the prefix in the Makefile. If RUNTIME_PREFIX is set the prefix is computed from the location of the executable. In this case, system_path() tries to strip known directories that executables can be located in from the path of the executable. If the path is successfully stripped it is used as the prefix. For example, if the executable is "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is "/msysgit". If the runtime prefix computation fails, we fall back to the static prefix specified in the makefile. This can be the case if the executable is not installed at a known location. Note that our test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global configuration files during testing. Hence testing does not trigger the fall back. Note that RUNTIME_PREFIX only works on Windows, though adding support on Unix should not be too hard. The implementation requires argv0_path to be set to an absolute path. argv0_path must point to the directory of the executable. We use assert() to verify this in debug builds. On Windows, the wrapper for main() (see compat/mingw.h) guarantees that argv0_path is correctly initialized. On Unix, further work is required before RUNTIME_PREFIX can be enabled. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 15:00:14 +03:00
#ifdef RUNTIME_PREFIX
assert(argv0_path);
assert(is_absolute_path(argv0_path));
if (!prefix &&
!(prefix = strip_path_suffix(argv0_path, GIT_EXEC_PATH)) &&
!(prefix = strip_path_suffix(argv0_path, BINDIR)) &&
!(prefix = strip_path_suffix(argv0_path, "git"))) {
Compute prefix at runtime if RUNTIME_PREFIX is set This commit adds support for relocatable binaries (called RUNTIME_PREFIX). Such binaries can be moved together with the system configuration files to a different directory, as long as the relative paths from the binary to the configuration files is preserved. This functionality is essential on Windows where we deliver git binaries with an installer that allows to freely choose the installation location. If RUNTIME_PREFIX is unset we use the static prefix. This will be the default on Unix. Thus, the behavior on Unix will remain identical to the old implementation, which used to add the prefix in the Makefile. If RUNTIME_PREFIX is set the prefix is computed from the location of the executable. In this case, system_path() tries to strip known directories that executables can be located in from the path of the executable. If the path is successfully stripped it is used as the prefix. For example, if the executable is "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is "/msysgit". If the runtime prefix computation fails, we fall back to the static prefix specified in the makefile. This can be the case if the executable is not installed at a known location. Note that our test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global configuration files during testing. Hence testing does not trigger the fall back. Note that RUNTIME_PREFIX only works on Windows, though adding support on Unix should not be too hard. The implementation requires argv0_path to be set to an absolute path. argv0_path must point to the directory of the executable. We use assert() to verify this in debug builds. On Windows, the wrapper for main() (see compat/mingw.h) guarantees that argv0_path is correctly initialized. On Unix, further work is required before RUNTIME_PREFIX can be enabled. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 15:00:14 +03:00
prefix = PREFIX;
trace_printf("RUNTIME_PREFIX requested, "
Compute prefix at runtime if RUNTIME_PREFIX is set This commit adds support for relocatable binaries (called RUNTIME_PREFIX). Such binaries can be moved together with the system configuration files to a different directory, as long as the relative paths from the binary to the configuration files is preserved. This functionality is essential on Windows where we deliver git binaries with an installer that allows to freely choose the installation location. If RUNTIME_PREFIX is unset we use the static prefix. This will be the default on Unix. Thus, the behavior on Unix will remain identical to the old implementation, which used to add the prefix in the Makefile. If RUNTIME_PREFIX is set the prefix is computed from the location of the executable. In this case, system_path() tries to strip known directories that executables can be located in from the path of the executable. If the path is successfully stripped it is used as the prefix. For example, if the executable is "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is "/msysgit". If the runtime prefix computation fails, we fall back to the static prefix specified in the makefile. This can be the case if the executable is not installed at a known location. Note that our test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global configuration files during testing. Hence testing does not trigger the fall back. Note that RUNTIME_PREFIX only works on Windows, though adding support on Unix should not be too hard. The implementation requires argv0_path to be set to an absolute path. argv0_path must point to the directory of the executable. We use assert() to verify this in debug builds. On Windows, the wrapper for main() (see compat/mingw.h) guarantees that argv0_path is correctly initialized. On Unix, further work is required before RUNTIME_PREFIX can be enabled. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 15:00:14 +03:00
"but prefix computation failed. "
"Using static fallback '%s'.\n", prefix);
}
#endif
strbuf_addf(&d, "%s/%s", prefix, path);
return strbuf_detach(&d, NULL);
}
common-main: stop munging argv[0] path Since 650c44925 (common-main: call git_extract_argv0_path(), 2016-07-01), the argv[0] that is seen in cmd_main() of individual programs is always the basename of the executable, as common-main strips off the full path. This can produce confusing results for git-daemon, which wants to re-exec itself. For instance, if the program was originally run as "/usr/lib/git/git-daemon", it will try just re-execing "git-daemon", which will find the first instance in $PATH. If git's exec-path has not been prepended to $PATH, we may find the git-daemon from a different version (or no git-daemon at all). Normally this isn't a problem. Git commands are run as "git daemon", the git wrapper puts the exec-path at the front of $PATH, and argv[0] is already "daemon" anyway. But running git-daemon via its full exec-path, while not really a recommended method, did work prior to 650c44925. Let's make it work again. The real goal of 650c44925 was not to munge argv[0], but to reliably set the argv0_path global. The only reason it munges at all is that one caller, the git.c wrapper, piggy-backed on that computation to find the command basename. Instead, let's leave argv[0] untouched in common-main, and have git.c do its own basename computation. While we're at it, let's drop the return value from git_extract_argv0_path(). It was only ever used in this one callsite, and its dual purposes is what led to this confusion in the first place. Note that by changing the interface, the compiler can confirm for us that there are no other callers storing the return value. But the compiler can't tell us whether any of the cmd_main() functions (besides git.c) were relying on the basename munging. However, we can observe that prior to 650c44925, no other cmd_main() functions did that munging, and no new cmd_main() functions have been introduced since then. So we can't be regressing any of those cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-27 07:31:13 +03:00
void git_extract_argv0_path(const char *argv0)
{
const char *slash;
if (!argv0 || !*argv0)
common-main: stop munging argv[0] path Since 650c44925 (common-main: call git_extract_argv0_path(), 2016-07-01), the argv[0] that is seen in cmd_main() of individual programs is always the basename of the executable, as common-main strips off the full path. This can produce confusing results for git-daemon, which wants to re-exec itself. For instance, if the program was originally run as "/usr/lib/git/git-daemon", it will try just re-execing "git-daemon", which will find the first instance in $PATH. If git's exec-path has not been prepended to $PATH, we may find the git-daemon from a different version (or no git-daemon at all). Normally this isn't a problem. Git commands are run as "git daemon", the git wrapper puts the exec-path at the front of $PATH, and argv[0] is already "daemon" anyway. But running git-daemon via its full exec-path, while not really a recommended method, did work prior to 650c44925. Let's make it work again. The real goal of 650c44925 was not to munge argv[0], but to reliably set the argv0_path global. The only reason it munges at all is that one caller, the git.c wrapper, piggy-backed on that computation to find the command basename. Instead, let's leave argv[0] untouched in common-main, and have git.c do its own basename computation. While we're at it, let's drop the return value from git_extract_argv0_path(). It was only ever used in this one callsite, and its dual purposes is what led to this confusion in the first place. Note that by changing the interface, the compiler can confirm for us that there are no other callers storing the return value. But the compiler can't tell us whether any of the cmd_main() functions (besides git.c) were relying on the basename munging. However, we can observe that prior to 650c44925, no other cmd_main() functions did that munging, and no new cmd_main() functions have been introduced since then. So we can't be regressing any of those cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-27 07:31:13 +03:00
return;
slash = find_last_dir_sep(argv0);
common-main: stop munging argv[0] path Since 650c44925 (common-main: call git_extract_argv0_path(), 2016-07-01), the argv[0] that is seen in cmd_main() of individual programs is always the basename of the executable, as common-main strips off the full path. This can produce confusing results for git-daemon, which wants to re-exec itself. For instance, if the program was originally run as "/usr/lib/git/git-daemon", it will try just re-execing "git-daemon", which will find the first instance in $PATH. If git's exec-path has not been prepended to $PATH, we may find the git-daemon from a different version (or no git-daemon at all). Normally this isn't a problem. Git commands are run as "git daemon", the git wrapper puts the exec-path at the front of $PATH, and argv[0] is already "daemon" anyway. But running git-daemon via its full exec-path, while not really a recommended method, did work prior to 650c44925. Let's make it work again. The real goal of 650c44925 was not to munge argv[0], but to reliably set the argv0_path global. The only reason it munges at all is that one caller, the git.c wrapper, piggy-backed on that computation to find the command basename. Instead, let's leave argv[0] untouched in common-main, and have git.c do its own basename computation. While we're at it, let's drop the return value from git_extract_argv0_path(). It was only ever used in this one callsite, and its dual purposes is what led to this confusion in the first place. Note that by changing the interface, the compiler can confirm for us that there are no other callers storing the return value. But the compiler can't tell us whether any of the cmd_main() functions (besides git.c) were relying on the basename munging. However, we can observe that prior to 650c44925, no other cmd_main() functions did that munging, and no new cmd_main() functions have been introduced since then. So we can't be regressing any of those cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-11-27 07:31:13 +03:00
if (slash)
argv0_path = xstrndup(argv0, slash - argv0);
}
void git_set_argv_exec_path(const char *exec_path)
{
argv_exec_path = exec_path;
/*
* Propagate this setting to external programs.
*/
setenv(EXEC_PATH_ENVIRONMENT, exec_path, 1);
}
/* Returns the highest-priority, location to look for git programs. */
const char *git_exec_path(void)
{
static char *cached_exec_path;
if (argv_exec_path)
return argv_exec_path;
if (!cached_exec_path) {
const char *env = getenv(EXEC_PATH_ENVIRONMENT);
if (env && *env)
cached_exec_path = xstrdup(env);
else
cached_exec_path = system_path(GIT_EXEC_PATH);
}
return cached_exec_path;
}
static void add_path(struct strbuf *out, const char *path)
{
if (path && *path) {
strbuf_add_absolute_path(out, path);
strbuf_addch(out, PATH_SEP);
}
}
void setup_path(void)
{
const char *old_path = getenv("PATH");
struct strbuf new_path = STRBUF_INIT;
Modify setup_path() to only add git_exec_path() to PATH Searching git programs only in the highest priority location is sufficient. It does not make sense that some of the required programs are located at the highest priority location but other programs are picked up from a lower priority exec-path. If exec-path is overridden a complete set of commands should be provided, otherwise several different versions could get mixed, which is likely to cause confusion. If a user explicitly overrides the default location (by --exec-path or GIT_EXEC_PATH), we now expect that all the required programs are found there. Instead of adding the directories "argv_exec_path", "getenv(EXEC_PATH_ENVIRONMENT)", and "system_path(GIT_EXEC_PATH)" to PATH, we now rely on git_exec_path(), which implements the same order, but only returns the highest priority location to search for executables. Accessing only the location with highest priority is also required for testing executables built with RUNTIME_PREFIX. The call to system_path() should be avoided if RUNTIME_PREFIX is set and the executable is not installed at its final destination. Because we test before installing, we want to avoid calling system_path() during tests. The modifications in this commit avoid calling system_path(GIT_EXEC_PATH) if a higher-priority location is provided, which is the case when running the tests. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-18 15:00:13 +03:00
add_path(&new_path, git_exec_path());
if (old_path)
strbuf_addstr(&new_path, old_path);
else
strbuf_addstr(&new_path, _PATH_DEFPATH);
setenv("PATH", new_path.buf, 1);
strbuf_release(&new_path);
}
const char **prepare_git_cmd(struct argv_array *out, const char **argv)
{
argv_array_push(out, "git");
argv_array_pushv(out, argv);
return out->argv;
}
int execv_git_cmd(const char **argv) {
struct argv_array nargv = ARGV_ARRAY_INIT;
prepare_git_cmd(&nargv, argv);
trace_argv_printf(nargv.argv, "trace: exec:");
/* execvp() can only ever return if it fails */
sane_execvp("git", (char **)nargv.argv);
trace_printf("trace: exec failed: %s\n", strerror(errno));
argv_array_clear(&nargv);
return -1;
}
int execl_git_cmd(const char *cmd,...)
{
int argc;
const char *argv[MAX_ARGS + 1];
const char *arg;
va_list param;
va_start(param, cmd);
argv[0] = cmd;
argc = 1;
while (argc < MAX_ARGS) {
arg = argv[argc++] = va_arg(param, char *);
if (!arg)
break;
}
va_end(param);
if (MAX_ARGS <= argc)
return error("too many args to run %s", cmd);
argv[argc] = NULL;
return execv_git_cmd(argv);
}