mirror of
https://github.com/git/git.git
synced 2024-05-22 10:56:10 +02:00
6854a8f5c9
Since650c44925(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 to650c44925. Let's make it work again. The real goal of650c44925was 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 to650c44925, 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>
42 lines
1.1 KiB
C
42 lines
1.1 KiB
C
#include "cache.h"
|
|
#include "exec_cmd.h"
|
|
|
|
/*
|
|
* Many parts of Git have subprograms communicate via pipe, expect the
|
|
* upstream of a pipe to die with SIGPIPE when the downstream of a
|
|
* pipe does not need to read all that is written. Some third-party
|
|
* programs that ignore or block SIGPIPE for their own reason forget
|
|
* to restore SIGPIPE handling to the default before spawning Git and
|
|
* break this carefully orchestrated machinery.
|
|
*
|
|
* Restore the way SIGPIPE is handled to default, which is what we
|
|
* expect.
|
|
*/
|
|
static void restore_sigpipe_to_default(void)
|
|
{
|
|
sigset_t unblock;
|
|
|
|
sigemptyset(&unblock);
|
|
sigaddset(&unblock, SIGPIPE);
|
|
sigprocmask(SIG_UNBLOCK, &unblock, NULL);
|
|
signal(SIGPIPE, SIG_DFL);
|
|
}
|
|
|
|
int main(int argc, const char **argv)
|
|
{
|
|
/*
|
|
* Always open file descriptors 0/1/2 to avoid clobbering files
|
|
* in die(). It also avoids messing up when the pipes are dup'ed
|
|
* onto stdin/stdout/stderr in the child processes we spawn.
|
|
*/
|
|
sanitize_stdfds();
|
|
|
|
git_setup_gettext();
|
|
|
|
git_extract_argv0_path(argv[0]);
|
|
|
|
restore_sigpipe_to_default();
|
|
|
|
return cmd_main(argc, argv);
|
|
}
|