git/exec_cmd.c, branch v2.3.0

Merge branch 'jc/exec-cmd-system-path-leak-fix'

2014-12-22T20:27:01Z

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

system_path(): always return free'able memory to the caller

2014-12-01T00:39:47Z

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

use strbuf_add_absolute_path() to add absolute paths

2014-08-26T18:06:06Z

Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

run-command: treat inaccessible directories as ENOENT

2012-04-05T23:24:13Z

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

Name make_*_path functions more accurately

2011-03-17T23:08:30Z

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

exec_cmd: remove unused extern

2011-01-19T16:27:22Z

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

Merge branch 'cw/maint-exec-defpath'

2010-05-21T11:02:17Z

* cw/maint-exec-defpath: autoconf: Check if exists and set HAVE_PATHS_H exec_cmd.c: replace hard-coded path list with one from

exec_cmd.c: replace hard-coded path list with one from

2010-04-15T19:07:51Z

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 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

Print RUNTIME_PREFIX warning only when GIT_TRACE is set

2010-02-23T21:20:15Z

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

Merge branch 'js/maint-1.6.0-exec-path-env'

2009-03-26T07:27:03Z

* js/maint-1.6.0-exec-path-env: Propagate --exec-path setting to external commands via GIT_EXEC_PATH