user/sven/git.git/run-command.c, branch v1.8.0.2

Merge branch 'dg/run-command-child-cleanup'

2012-09-15T04:39:37Z

The code to wait for subprocess and remove it from our internal queue wasn't quite right. * dg/run-command-child-cleanup: run-command.c: fix broken list iteration in clear_child_for_cleanup

run-command.c: fix broken list iteration in clear_child_for_cleanup

2012-09-11T17:30:31Z

Iterate through children_to_clean using 'next' fields but with an extra level of indirection. This allows us to update the chain when we remove a child and saves us managing several variables around the loop mechanism. Signed-off-by: David Gould Acked-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/maint-sane-execvp-notdir'

2012-09-03T22:53:26Z

"git foo" errored out with "Not a directory" when the user had a non directory on $PATH, and worse yet it masked an alias "foo" to run. * jc/maint-sane-execvp-notdir: sane_execvp(): ignore non-directory on $PATH

sane_execvp(): ignore non-directory on $PATH

2012-07-31T19:51:30Z

When you have a non-directory on your PATH, a funny thing happens: $ PATH=$PATH:/bin/sh git foo fatal: cannot exec 'git-foo': Not a directory? Worse yet, as real commands always take precedence over aliases, this behaviour interacts rather badly with them: $ PATH=$PATH:/bin/sh git -c alias.foo=show git foo -s fatal: cannot exec 'git-foo': Not a directory? This is because an ENOTDIR error from the underlying execvp(2) is reported back to the caller of our sane_execvp() wrapper as-is. Translating it to ENOENT, just like the case where we _might_ have the command in an unreadable directory, fixes it. Without an alias, we would get git: 'foo' is not a git command. See 'git --help'. and we use the 'foo' alias when it is available, of course. Signed-off-by: Junio C Hamano

Merge branch 'js/spawn-via-shell-path-fix'

2012-04-20T22:51:18Z

Mops up an unfortunate fallout from bw/spawn-via-shell-path topic. By Johannes Sixt * js/spawn-via-shell-path-fix: Do not use SHELL_PATH from build system in prepare_shell_cmd on Windows

Merge branch 'jk/run-command-eacces'

2012-04-20T22:50:03Z

When PATH contains an unreadable directory, alias expansion code did not kick in, and failed with an error that said "git-subcmd" was not found. By Jeff King (1) and Ramsay Jones (1) * jk/run-command-eacces: run-command: treat inaccessible directories as ENOENT compat/mingw.[ch]: Change return type of exec functions to int

Do not use SHELL_PATH from build system in prepare_shell_cmd on Windows

2012-04-17T15:51:54Z

The recent change to use SHELL_PATH instead of "sh" to spawn shell commands is not suited for Windows: - The default setting, "/bin/sh", does not work when git has to run the shell because it is a POSIX style path, but not a proper Windows style path. - If it worked, it would hard-code a position in the files system where the shell is expected, making git (more precisely, the POSIX toolset that is needed alongside git) non-relocatable. But we cannot sacrifice relocatability on Windows. - Apart from that, even though the Makefile leaves SHELL_PATH set to "/bin/sh" for the Windows builds, the build system passes a mangled path to the compiler, and something like "D:/Src/msysgit/bin/sh" is used, which is doubly bad because it points to where /bin/sh resolves to on the system where git was built. - Finally, the system's CreateProcess() function that is used under mingw.c's hood does not work with forward slashes and cannot find the shell. Undo the earlier change on Windows. Signed-off-by: Johannes Sixt 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

Use SHELL_PATH from build system in run_command.c:prepare_shell_cmd

2012-04-04T00:24:20Z

During the testing of the 1.7.10 rc series on Solaris for OpenCSW, it was discovered that t7006-pager was failing due to finding a bad "sh" in PATH after a call to execvp("sh", ...). This call was setup by run_command.c:prepare_shell_cmd. The PATH in use at the time saw /opt/csw/bin given precedence to traditional Solaris paths such as /usr/bin and /usr/xpg4/bin. A package named schilyutils (Joerg Schilling's utilities) was installed on the build system and it delivered a modified version of the traditional Solaris /usr/bin/sh as /opt/csw/bin/sh. This version of sh suffers from many of the same problems as /usr/bin/sh. The command-specific pager test failed due to the broken "sh" handling ^ as a pipe character. It tried to fork two processes when it encountered "sed s/^/foo:/" as the pager command. This problem was entirely dependent on the PATH of the user at runtime. Possible fixes for this issue are: 1. Use the standard system() or popen() which both launch a POSIX shell on Solaris as long as _POSIX_SOURCE is defined. 2. The git wrapper could prepend SANE_TOOL_PATH to PATH thus forcing all unqualified commands run to use the known good tools on the system. 3. The run_command.c:prepare_shell_command() could use the same SHELL_PATH that is in the #! line of all all scripts and not rely on PATH to find the sh to run. Option 1 would preclude opening a bidirectional pipe to a filter script and would also break git for Windows as cmd.exe is spawned from system() (cf. v1.7.5-rc0~144^2, "alias: use run_command api to execute aliases, 2011-01-07). Option 2 is not friendly to users as it would negate their ability to use tools of their choice in many cases. Alternately, injecting SANE_TOOL_PATH such that it takes precedence over /bin and /usr/bin (and anything with lower precedence than those paths) as git-sh-setup.sh does would not solve the problem either as the user environment could still allow a bad sh to be found. (Many OpenCSW users will have /opt/csw/bin leading their PATH and some subset would have schilyutils installed.) Option 3 allows us to use a known good shell while still honouring the users' PATH for the utilities being run. Thus, it solves the problem while not negatively impacting either users or git's ability to run external commands in convenient ways. Essentially, the shell is a special case of tool that should not rely on SANE_TOOL_PATH and must be called explicitly. With this patch applied, any code path leading to run_command.c:prepare_shell_cmd can count on using the same sane shell that all shell scripts in the git suite use. Both the build system and run_command.c will default this shell to /bin/sh unless overridden. Signed-off-by: Ben Walton Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

dashed externals: kill children on exit

2012-01-08T23:07:20Z

Several git commands are so-called dashed externals, that is commands executed as a child process of the git wrapper command. If the git wrapper is killed by a signal, the child process will continue to run. This is different from internal commands, which always die with the git wrapper command. Enable the recently introduced cleanup mechanism for child processes in order to make dashed externals act more in line with internal commands. Signed-off-by: Clemens Buchacher Acked-by: Jeff King Signed-off-by: Junio C Hamano