path: root/exec_cmd.c
AgeCommit message (Collapse)Author
2018-04-11exec_cmd: rename to use dash in file nameStefan Beller
This is more consistent with the project style. The majority of Git's source files use dashes in preference to underscores in their file names. Signed-off-by: Stefan Beller <>
2017-09-07git_extract_argv0_path: do nothing without RUNTIME_PREFIXJeff King
When the RUNTIME_PREFIX compile-time knob isn't set, we never look at the argv0_path we extract. We can push its declaration inside the #ifdef to make it more clear that the extract code is effectively a noop. This also un-confuses leak-checking of the argv0_path variable when RUNTIME_PREFIX isn't set. The compiler is free to drop this static variable that we set but never look at (and "gcc -O2" does so). But the compiler still must call strbuf_detach(), since it doesn't know whether that function has side effects; it just throws away the result rather than putting it into the global. Leak-checkers which work by scanning the data segment for pointers to heap blocks would normally consider the block as reachable at program end. But if the compiler removes the variable entirely, there's nothing to find. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-09-07system_path: move RUNTIME_PREFIX to a sub-functionJeff King
The system_path() function has an #ifdef in the middle of it. Let's move the conditional logic into a sub-function. This isolates it more, which will make it easier to change and add to. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-01-31Merge branch 'js/exec-path-coverity-workaround'Junio C Hamano
Code cleanup. * js/exec-path-coverity-workaround: git_exec_path: do not return the result of getenv() git_exec_path: avoid Coverity warning about unfree()d result
2017-01-09git_exec_path: do not return the result of getenv()Jeff King
The result of getenv() is not guaranteed by POSIX to last beyond another call to getenv(), or setenv(), etc. We should duplicate the string before returning to the caller to avoid any surprises. We already keep a cached pointer to avoid repeatedly leaking the result of system_path(). We can use the same pointer here to avoid allocating and leaking for each call. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-01-09git_exec_path: avoid Coverity warning about unfree()d resultJohannes Schindelin
Technically, it is correct that git_exec_path() returns a possibly malloc()ed string returned from system_path(), and it is sometimes not allocated. Cache the result in a static variable and make sure that we call system_path() only once, which plugs a potential leak. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2016-11-29common-main: stop munging argv[0] pathJeff King
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 <> Signed-off-by: Junio C Hamano <>
2016-02-26Merge branch 'jk/tighten-alloc'Junio C Hamano
Update various codepaths to avoid manually-counted malloc(). * jk/tighten-alloc: (22 commits) ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation ...
2016-02-22prepare_{git,shell}_cmd: use argv_arrayJeff King
These functions transform an existing argv into one suitable for exec-ing or spawning via git or a shell. We can use an argv_array in each to avoid dealing with manual counting and allocation. This also makes the memory allocation more clear and fixes some leaks. In prepare_shell_cmd, we would sometimes allocate a new string with "$@" in it and sometimes not, meaning the caller could not correctly free it. On the non-Windows side, we are in a child process which will exec() or exit() immediately, so the leak isn't a big deal. On Windows, though, we use spawn() from the parent process, and leak a string for each shell command we run. On top of that, the Windows code did not free the allocated argv array at all (but does for the prepare_git_cmd case!). By switching both of these functions to write into an argv_array, we can consistently free the result as appropriate. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-02-19exec_cmd.c: use find_last_dir_sep() for code simplificationAlexander Kuleshov
We are trying to extract dirname from argv0 in the git_extract_argv0_path(). But in the same time, the <git-compat-util.h> provides find_last_dir_sep() to get dirname from a given path. Let's use it instead of loop for the code simplification. Signed-off-by: Alexander Kuleshov <> Signed-off-by: Junio C Hamano <>
2015-05-26Merge branch 'jk/git-no-more-argv0-path-munging' into maintJunio C Hamano
We have prepended $GIT_EXEC_PATH and the path "git" is installed in (typically "/usr/bin") to $PATH when invoking subprograms and hooks for almost eternity, but the original use case the latter tried to support was semi-bogus (i.e. install git to /opt/foo/git and run it without having /opt/foo on $PATH), and more importantly it has become less and less relevant as Git grew more mainstream (i.e. the users would _want_ to have it on their $PATH). Stop prepending the path in which "git" is installed to users' $PATH, as that would interfere the command search order people depend on (e.g. they may not like versions of programs that are unrelated to Git in /usr/bin and want to override them by having different ones in /usr/local/bin and have the latter directory earlier in their $PATH). * jk/git-no-more-argv0-path-munging: stop putting argv[0] dirname at front of PATH
2015-05-19Merge branch 'jk/git-no-more-argv0-path-munging'Junio C Hamano
We have prepended $GIT_EXEC_PATH and the path "git" is installed in (typically "/usr/bin") to $PATH when invoking subprograms and hooks for almost eternity, but the original use case the latter tried to support was semi-bogus (i.e. install git to /opt/foo/git and run it without having /opt/foo on $PATH), and more importantly it has become less and less relevant as Git grew more mainstream (i.e. the users would _want_ to have it on their $PATH). Stop prepending the path in which "git" is installed to users' $PATH, as that would interfere the command search order people depend on (e.g. they may not like versions of programs that are unrelated to Git in /usr/bin and want to override them by having different ones in /usr/local/bin and have the latter directory earlier in their $PATH). * jk/git-no-more-argv0-path-munging: stop putting argv[0] dirname at front of PATH
2015-04-22stop putting argv[0] dirname at front of PATHJeff King
When the "git" wrapper is invoked, we prepend the baked-in exec-path to our PATH, so that any sub-processes we exec will all find the git-foo commands that match the wrapper version. If you invoke git with an absolute path, like: /usr/bin/git foo we also prepend "/usr/bin" to the PATH. This was added long ago by by 231af83 (Teach the "git" command to handle some commands internally, 2006-02-26), with the intent that things would just work if you did something like: cd /opt tar xzf premade-git-package.tar.gz alias git=/opt/git/bin/git as we would then find all of the related external commands in /opt/git/bin. I.e., it made git runtime-relocatable, since at the time of 231af83, we installed all of the git commands into $(bindir). But these days, that is not enough. Since f28ac70 (Move all dashed-form commands to libexecdir, 2007-11-28), we do not put commands into $(bindir), and you actually need to convert "/usr/bin" into "/usr/libexec". And not just for finding binaries; we want to find $(sharedir), etc, the same way. The RUNTIME_PREFIX build knob does this the right way, by assuming a sane hierarchy rooted at "$prefix" when we run "$prefix/bin/git", and inferring "$prefix/libexec/git-core", etc. So this feature (prepending the argv[0] dirname to the PATH) is broken for providing a runtime prefix, and has been for many years. Does it do anything for other cases? For the "git" wrapper itself, as well as any commands shipped by "git", the answer is no. Those are already in git's exec-path, which is consulted first. For third-party commands which you've dropped into the same directory, it does include them. So if you do cd /opt tar xzf git-built-specifically-for-opt-git.tar.gz cp third-party/git-foo /opt/git/bin/git-foo alias git=/opt/git/bin/git it does mean that we will find the third-party "git-foo", even if you do not put /opt/git/bin into your $PATH. But the flipside of this is that we will bump the precedence of _other_ third-party tools that happen to be in the same directory as git. For example, consider this setup: 1. Git is installed by the system in /usr/bin. There are other system utilities in /usr/bin. E.g., a system "vi". 2. The user installs tools they prefer in /usr/local/bin. E.g., vim with a "vi" symlink. They set their PATH to /usr/local/bin:/usr/bin to prefer their custom tools. 3. Running /usr/bin/git puts "/usr/bin" at the front of their PATH. When git invokes the editor on behalf of the user, they get the system vi, not their normal vim. There are other variants of this, including overriding system ruby and python (which is quite common using tools like "rvm" and "virtualenv", which use relocatable hierarchies and $PATH settings to get a consistent environment). Given that the main motivation for git placing the argv[0] dirname into the PATH has been broken for years, that the remaining cases are obscure and unlikely (and easily fixed by the user just setting up their $PATH sanely), and that the behavior is hurting real, reasonably common use cases, it's not worth continuing to do so. Signed-off-by: Jeff King <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2014-12-22Merge branch 'jc/exec-cmd-system-path-leak-fix'Junio C Hamano
The function sometimes returned a non-freeable memory and some other times returned a piece of memory that must be freed. * jc/exec-cmd-system-path-leak-fix: system_path(): always return free'able memory to the caller
2014-12-01system_path(): always return free'able memory to the callerJunio C Hamano
The function sometimes returns a newly allocated string and sometimes returns a borrowed string, the latter of which the callers must not free(). The existing callers all assume that the return value belongs to the callee and most of them copy it with strdup() when they want to keep it around. They end up leaking the returned copy when the callee returned a new string because they cannot tell if they should free it. Change the contract between the callers and system_path() to make the returned string owned by the callers; they are responsible for freeing it when done, but they do not have to make their own copy to store it away. Adjust the callers to make sure they do not leak the returned string once they are done, but do not bother freeing it just before dying, exiting or exec'ing other program to avoid unnecessary churn. Reported-by: Alexander Kuleshov <> Signed-off-by: Junio C Hamano <>
2014-08-26use strbuf_add_absolute_path() to add absolute pathsRené Scharfe
Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2012-04-05run-command: treat inaccessible directories as ENOENTJeff King
When execvp reports EACCES, it can be one of two things: 1. We found a file to execute, but did not have permissions to do so. 2. We did not have permissions to look in some directory in the $PATH. In the former case, we want to consider this a permissions problem and report it to the user as such (since getting this for something like "git foo" is likely a configuration error). In the latter case, there is a good chance that the inaccessible directory does not contain anything of interest. Reporting "permission denied" is confusing to the user (and prevents our usual "did you mean...?" lookup). It also prevents git from trying alias lookup, since we do so only when an external command does not exist (not when it exists but has an error). This patch detects EACCES from execvp, checks whether we are in case (2), and if so converts errno to ENOENT. This behavior matches that of "bash" (but not of simpler shells that use execvp more directly, like "dash"). Test stolen from Junio. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-03-17Name make_*_path functions more accuratelyCarlos Martín Nieto
Rename the make_*_path functions so it's clearer what they do, in particlar make clear what the differnce between make_absolute_path and make_nonrelative_path is by renaming them real_path and absolute_path respectively. make_relative_path has an understandable name and is renamed to relative_path to maintain the name convention. The function calls have been replaced 1-to-1 in their usage. Signed-off-by: Carlos Martín Nieto <> Signed-off-by: Junio C Hamano <>
2011-01-19exec_cmd: remove unused externErik Faye-Lund
This definition was added by commit 77cb17e9, but it's left unused since commit 511707d. Remove the left-over definition. Signed-off-by: Erik Faye-Lund <> Signed-off-by: Junio C Hamano <>
2010-05-21Merge branch 'cw/maint-exec-defpath'Junio C Hamano
* cw/maint-exec-defpath: autoconf: Check if <paths.h> exists and set HAVE_PATHS_H exec_cmd.c: replace hard-coded path list with one from <paths.h>
2010-04-15exec_cmd.c: replace hard-coded path list with one from <paths.h>Chris Webb
The default executable path list used by exec_cmd.c is hard-coded to be "/usr/local/bin:/usr/bin:/bin". Use an appropriate value for the system from <paths.h> when available. Add HAVE_PATHS_H make variables and enable it on Linux, FreeBSD, NetBSD, OpenBSD and GNU where it is known to exist for now. Somebody else may want to do an autoconf support later. Signed-off-by: Chris Webb <> Signed-off-by: Junio C Hamano <>
2010-02-23Print RUNTIME_PREFIX warning only when GIT_TRACE is setJohannes Sixt
When RUNTIME_PREFIX is enabled, the installation prefix is derived by trying a limited set of known locations where the git executable can reside. If none of these is found, a warning is emitted. When git is built in a directory that matches neither of these known names, the warning would always be emitted when the uninstalled executable is run. This is a problem on Windows, where gitk picks the uninstalled git when invoked from the build directory and gets confused by the warning. Print the warning only when GIT_TRACE is set. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-03-26Merge branch 'js/maint-1.6.0-exec-path-env'Junio C Hamano
* js/maint-1.6.0-exec-path-env: Propagate --exec-path setting to external commands via GIT_EXEC_PATH
2009-03-22Propagate --exec-path setting to external commands via GIT_EXEC_PATHJohannes Sixt
Let PATH0=$PATH that was set before the invocation. Let /foo be a build directory. Let /pfx be the installation prefix. Let pfxexecpath=/pfx/libexec/git-core. The following is going on when 'git --exec-path=/foo gc' is invoked: 1. git sets PATH=/foo:$PATH0 using the path from --exec-path 2. gc execs 'git repack' (note: no dash). 3. Since there is a git in /foo (it's a build directory), /foo/git is taken. 4. No explicit exec-path is set this time, hence, this secondary git sets PATH=$pfxexecpath:/foo:$PATH 5. Since 'repack' is not a built-in, execv_dashed_external execs 'git-repack' (note: dash). 6. There is a $pfxexecpath/git-repack, and it is taken. 7. This git-repack runs 'git pack-objects' (note: no dash). 8. There is no git in $pfxexecpath, but there is one in /foo. Hence, /foo/git is run. 9. pack-objects is a builtin, hence, in effect /foo/git-pack-objects is run. As you can see, the way in which we previously set the PATH allowed to mix gits of different vintage. By setting GIT_EXEC_PATH when --exec-path was given on the command line, we reduce the confusion. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-02-20system_path(): simplify using strip_path_suffix(), and add suffix "git"Johannes Schindelin
At least for the author of this patch, the logic in system_path() was too hard to understand. Using the function strip_path_suffix() documents the idea of the code better. The real change is to add the suffix "git", so that a runtime prefix will be computed correctly even when the executable was called in /git/ as is the case in msysGit (Windows insists to search the current directory before the PATH when looking for an executable). Signed-off-by: Johannes Schindelin <> Acked-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-01-26Compute prefix at runtime if RUNTIME_PREFIX is setSteffen Prohaska
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 <> Acked-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-01-26Modify setup_path() to only add git_exec_path() to PATHSteffen Prohaska
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 <> Acked-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-01-26git_extract_argv0_path(): Move check for valid argv0 from caller to calleeSteffen Prohaska
This simplifies the calling code. Signed-off-by: Steffen Prohaska <> Acked-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-01-26Refactor git_set_argv0_path() to git_extract_argv0_path()Steve Haslam
This commit moves the code that computes the dirname of argv[0] from git.c's main() to git_set_argv0_path() and renames the function to git_extract_argv0_path(). This makes the code in git.c's main less cluttered, and we can use the dirname computation from other main() functions too. [ spr: - split Steve's original commit and wrote new commit message. - Integrated Johannes Schindelin's cca1704897e7fdb182f68d4c48a437c5d7bc5203 while rebasing onto master. ] Signed-off-by: Steve Haslam <> Signed-off-by: Steffen Prohaska <> Acked-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-01-26Move computation of absolute paths from Makefile to runtime (in preparation ↵Steffen Prohaska
for RUNTIME_PREFIX) This commit prepares the Makefile for relocatable binaries (called RUNTIME_PREFIX). Such binaries will be able to be moved together with the system configuration files to a different directory, requiring to compute the prefix at runtime. In a first step, we make all paths relative in the Makefile and teach system_path() to add the prefix instead. We used to compute absolute paths in the Makefile and passed them to C as defines. We now pass relative paths to C and call system_path() to add the prefix at runtime. Signed-off-by: Steffen Prohaska <> Acked-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerBrandon Casey
Many call sites use strbuf_init(&foo, 0) to initialize local strbuf variable "foo" which has not been accessed since its declaration. These can be replaced with a static initialization using the STRBUF_INIT macro which is just as readable, saves a function call, and takes up fewer lines. Signed-off-by: Brandon Casey <> Signed-off-by: Shawn O. Pearce <>
2008-07-29Refactor, adding prepare_git_cmd(const char **argv)Steffen Prohaska
prepare_git_cmd(const char **argv) adds a first entry "git" to the array argv. The new array is allocated on the heap. It's the caller's responsibility to release it with free(). The code was already present in execv_git_cmd() but could not be used from outside. Now it can also be called for preparing the command list in the MinGW codepath in run-command.c. Signed-off-by: Steffen Prohaska <> Signed-off-by: Junio C Hamano <>
2008-07-26Allow add_path() to add non-existent directories to the pathJohannes Sixt
This function had used make_absolute_path(); but this function dies if the directory that contains the entry whose relative path was supplied in the argument does not exist. This is a problem if the argument is, for example, "../libexec/git-core", and that "../libexec" does not exist. Since the resolution of symbolic links is not required for elements in PATH, we can fall back to using make_nonrelative_path(), which simply prepends $PWD to the path. We have to move make_nonrelative_path() alongside make_absolute_path() in abspath.c so that git-shell can be linked. See 5b8e6f85f. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-07-26Allow the built-in exec path to be relative to the command invocation pathJohannes Sixt
If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative, it is interpreted relative to the command's invocation path, which usually is $(bindir). The Makefile rules were written with the assumption that $(gitexecdir) is an absolute path. We introduce a separate variable that names the (absolute) installation directory. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-07-26Fix relative built-in paths to be relative to the command invocationJohannes Sixt
$(gitexecdir) (as defined in the Makefile) has gained another path component, but the relative paths in the MINGW section of the Makefile, which are interpreted relative to it, do not account for it. Instead of adding another ../ in front of the path, we change the code that constructs the absolute paths to do it relative to the command's directory, which is essentially $(bindir). We do it this way because we will also allow a relative $(gitexecdir) later. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-07-26Record the command invocation path earlyJohannes Sixt
We will need the command invocation path in system_path(). This path was passed to setup_path(), but system_path() can be called earlier, for example via: main commit_pager_choice setup_pager git_config git_etc_gitconfig system_path Therefore, we introduce git_set_argv0_path() and call it as soon as possible. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-07-13Move code interpreting path relative to exec-dir to new function system_path()Steffen Prohaska
Expanding system paths relative to git_exec_path can be used for creating an installation that can be moved to a different directory without re-compiling. We use this approach for template_dir and the system wide gitconfig. The Windows installer (msysgit) is an example for such a setup. This commit moves common code to a new function system_path(). System paths that are to be interpreted relative to git_exec_path are passed to system_path() and the return value is used instead of the original path. system_path() prefixes a relative path with git_exec_path and leaves absolute paths unmodified. For example, we now write template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR); [j6t: moved from path.c to exec_cmd.c] Signed-off-by: Steffen Prohaska <> Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2008-07-03Merge branch 'j6t/mingw'Junio C Hamano
* j6t/mingw: (38 commits) compat/pread.c: Add a forward declaration to fix a warning Windows: Fix ntohl() related warnings about printf formatting Windows: TMP and TEMP environment variables specify a temporary directory. Windows: Make 'git help -a' work. Windows: Work around an oddity when a pipe with no reader is written to. Windows: Make the pager work. When installing, be prepared that template_dir may be relative. Windows: Use a relative default template_dir and ETC_GITCONFIG Windows: Compute the fallback for exec_path from the program invocation. Turn builtin_exec_path into a function. Windows: Use a customized struct stat that also has the st_blocks member. Windows: Add a custom implementation for utime(). Windows: Add a new lstat and fstat implementation based on Win32 API. Windows: Implement a custom spawnve(). Windows: Implement wrappers for gethostbyname(), socket(), and connect(). Windows: Work around incompatible sort and find. Windows: Implement asynchronous functions as threads. Windows: Disambiguate DOS style paths from SSH URLs. Windows: A rudimentary poll() emulation. Windows: Implement start_command(). ...
2008-06-26Windows: Compute the fallback for exec_path from the program invocation.Johannes Sixt
Since on Windows the user is fairly free where to install programs, we cannot rely on a hard-coded path. We use the program name to derive the installation directory and use that as exec_path. Signed-off-by: Johannes Sixt <>
2008-06-26Turn builtin_exec_path into a function.Johannes Sixt
builtin_exec_path returns the hard-coded installation path, which is used as the ultimate fallback to look for git commands. Making it into a function enables us in a follow-up patch to return a computed value instead of just a constant string. Signed-off-by: Johannes Sixt <>
2008-06-24Prepare execv_git_cmd() for removal of builtins from the filesystemJunio C Hamano
Currently, execv_git_cmd() always try running the dashed form, which means we cannot easily remove the git-foo hardlinks for built-in commands. This updates the function to always exec "git foo" form, and makes sure "git" potty does not infinitely recurse to itself. Signed-off-by: Junio C Hamano <>
2008-06-22Windows: Use the Windows style PATH separator ';'.Johannes Sixt
Signed-off-by: Johannes Sixt <>
2007-12-04Trace and quote with argv: get rid of unneeded count argument.Christian Couder
Now that str_buf takes care of all the allocations, there is no more gain to pass an argument count. So this patch removes the "count" argument from: - "sq_quote_argv" - "trace_argv_printf" and all the callers. Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2007-10-30use only the $PATH for exec'ing git commandsScott R Parish
We need to correctly set up $PATH for non-c based git commands. Since we already do this, we can just use that $PATH and execvp, instead of looping over the paths with execve. This patch adds a setup_path() function to exec_cmd.c, which sets the $PATH order correctly for our search order. execv_git_cmd() is stripped down to setting up argv and calling execvp(). git.c's main() only only needs to call setup_path(). Signed-off-by: Scott R Parish <> Signed-off-by: Junio C Hamano <>
2007-10-30"current_exec_path" is a misleading name, use "argv_exec_path"Scott R Parish
Signed-off-by: Scott R Parish <> Signed-off-by: Junio C Hamano <>
2007-02-21Mechanical conversion to use prefixcmp()Junio C Hamano
This mechanically converts strncmp() to use prefixcmp(), but only when the parameters match specific patterns, so that they can be verified easily. Leftover from this will be fixed in a separate step, including idiotic conversions like if (!strncmp("foo", arg, 3)) => if (!(-prefixcmp(arg, "foo"))) This was done by using this script in px.perl #!/usr/bin/perl -i.bak -p if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) { s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|; } if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) { s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|; } and running: $ git grep -l strncmp -- '*.c' | xargs perl px.perl Signed-off-by: Junio C Hamano <>
2006-12-19Use preprocessor constants for environment variable names.Junio C Hamano
We broke the discipline Linus set up to allow compiler help us avoid typos in environment names in the early days of git over time. This defines a handful preprocessor constants for environment variable names used in relatively core parts of the system. I've left out variable names specific to subsystems such as HTTP and SSL as I do not think they are big problems. Signed-off-by: Junio C Hamano <>
2006-08-31Trace into open fd and refactor tracing code.Christian Couder
Now if GIT_TRACE is set to an integer value greater than 1 and lower than 10, we interpret this as an open fd value and we trace into it. Note that this behavior is not compatible with the previous one. We also trace whole messages using one write(2) call to make sure messages from processes do net get mixed up in the middle. It's now possible to run the tests like this: GIT_TRACE=9 make test 9>/var/tmp/trace.log Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2006-08-16remove unnecessary initializationsDavid Rientjes
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <> Signed-off-by: Junio C Hamano <>
2006-07-09GIT_TRACE: fix a mixed declarations and code warningTimo Hirvonen
Signed-off-by: Timo Hirvonen <> Signed-off-by: Junio C Hamano <>