|
|
|
|
#include "cache.h"
|
spawn pager via run_command interface
This has two important effects:
1. The pager is now the _child_ process, instead of the
parent. This means that whatever spawned git (e.g., the
shell) will see the exit code of the git process, and
not the pager.
2. The mingw and regular code are now unified, which makes
the setup_pager function much simpler.
There are two caveats:
1. We used to call execlp directly on the pager, followed
by trying to exec it via the shall. We now just use the
shell (which is what mingw has always done). This may
have different results for pager names which contain
shell metacharacters.
It is also slightly less efficient because we
unnecessarily run the shell; however, pager spawning is
by definition an interactive task, so it shouldn't be
a huge problem.
2. The git process will remain in memory while the user
looks through the pager. This is potentially wasteful.
We could get around this by turning the parent into a
meta-process which spawns _both_ git and the pager,
collects the exit status from git, waits for both to
end, and then exits with git's exit code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
#include "run-command.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is split up from the rest of git so that we can do
|
|
|
|
|
* something different on Windows.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static int spawned_pager;
|
|
|
|
|
|
|
|
|
|
#ifndef __MINGW32__
|
spawn pager via run_command interface
This has two important effects:
1. The pager is now the _child_ process, instead of the
parent. This means that whatever spawned git (e.g., the
shell) will see the exit code of the git process, and
not the pager.
2. The mingw and regular code are now unified, which makes
the setup_pager function much simpler.
There are two caveats:
1. We used to call execlp directly on the pager, followed
by trying to exec it via the shall. We now just use the
shell (which is what mingw has always done). This may
have different results for pager names which contain
shell metacharacters.
It is also slightly less efficient because we
unnecessarily run the shell; however, pager spawning is
by definition an interactive task, so it shouldn't be
a huge problem.
2. The git process will remain in memory while the user
looks through the pager. This is potentially wasteful.
We could get around this by turning the parent into a
meta-process which spawns _both_ git and the pager,
collects the exit status from git, waits for both to
end, and then exits with git's exit code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
static void pager_preexec(void)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* Work around bug in "less" by not starting it until we
|
|
|
|
|
* have real input
|
|
|
|
|
*/
|
|
|
|
|
fd_set in;
|
|
|
|
|
|
|
|
|
|
FD_ZERO(&in);
|
|
|
|
|
FD_SET(0, &in);
|
|
|
|
|
select(1, &in, NULL, &in, NULL);
|
|
|
|
|
|
spawn pager via run_command interface
This has two important effects:
1. The pager is now the _child_ process, instead of the
parent. This means that whatever spawned git (e.g., the
shell) will see the exit code of the git process, and
not the pager.
2. The mingw and regular code are now unified, which makes
the setup_pager function much simpler.
There are two caveats:
1. We used to call execlp directly on the pager, followed
by trying to exec it via the shall. We now just use the
shell (which is what mingw has always done). This may
have different results for pager names which contain
shell metacharacters.
It is also slightly less efficient because we
unnecessarily run the shell; however, pager spawning is
by definition an interactive task, so it shouldn't be
a huge problem.
2. The git process will remain in memory while the user
looks through the pager. This is potentially wasteful.
We could get around this by turning the parent into a
meta-process which spawns _both_ git and the pager,
collects the exit status from git, waits for both to
end, and then exits with git's exit code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
setenv("LESS", "FRSX", 0);
|
|
|
|
|
}
|
spawn pager via run_command interface
This has two important effects:
1. The pager is now the _child_ process, instead of the
parent. This means that whatever spawned git (e.g., the
shell) will see the exit code of the git process, and
not the pager.
2. The mingw and regular code are now unified, which makes
the setup_pager function much simpler.
There are two caveats:
1. We used to call execlp directly on the pager, followed
by trying to exec it via the shall. We now just use the
shell (which is what mingw has always done). This may
have different results for pager names which contain
shell metacharacters.
It is also slightly less efficient because we
unnecessarily run the shell; however, pager spawning is
by definition an interactive task, so it shouldn't be
a huge problem.
2. The git process will remain in memory while the user
looks through the pager. This is potentially wasteful.
We could get around this by turning the parent into a
meta-process which spawns _both_ git and the pager,
collects the exit status from git, waits for both to
end, and then exits with git's exit code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
static const char *pager_argv[] = { "sh", "-c", NULL, NULL };
|
spawn pager via run_command interface
This has two important effects:
1. The pager is now the _child_ process, instead of the
parent. This means that whatever spawned git (e.g., the
shell) will see the exit code of the git process, and
not the pager.
2. The mingw and regular code are now unified, which makes
the setup_pager function much simpler.
There are two caveats:
1. We used to call execlp directly on the pager, followed
by trying to exec it via the shall. We now just use the
shell (which is what mingw has always done). This may
have different results for pager names which contain
shell metacharacters.
It is also slightly less efficient because we
unnecessarily run the shell; however, pager spawning is
by definition an interactive task, so it shouldn't be
a huge problem.
2. The git process will remain in memory while the user
looks through the pager. This is potentially wasteful.
We could get around this by turning the parent into a
meta-process which spawns _both_ git and the pager,
collects the exit status from git, waits for both to
end, and then exits with git's exit code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
static struct child_process pager_process;
|
|
|
|
|
|
|
|
|
|
static void wait_for_pager(void)
|
|
|
|
|
{
|
|
|
|
|
fflush(stdout);
|
|
|
|
|
fflush(stderr);
|
|
|
|
|
/* signal EOF to pager */
|
|
|
|
|
close(1);
|
|
|
|
|
close(2);
|
|
|
|
|
finish_command(&pager_process);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void setup_pager(void)
|
|
|
|
|
{
|
|
|
|
|
const char *pager = getenv("GIT_PAGER");
|
|
|
|
|
|
|
|
|
|
if (!isatty(1))
|
|
|
|
|
return;
|
|
|
|
|
if (!pager) {
|
|
|
|
|
if (!pager_program)
|
|
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
pager = pager_program;
|
|
|
|
|
}
|
|
|
|
|
if (!pager)
|
|
|
|
|
pager = getenv("PAGER");
|
|
|
|
|
if (!pager)
|
|
|
|
|
pager = "less";
|
|
|
|
|
else if (!*pager || !strcmp(pager, "cat"))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
spawned_pager = 1; /* means we are emitting to terminal */
|
|
|
|
|
|
|
|
|
|
/* spawn the pager */
|
|
|
|
|
pager_argv[2] = pager;
|
spawn pager via run_command interface
This has two important effects:
1. The pager is now the _child_ process, instead of the
parent. This means that whatever spawned git (e.g., the
shell) will see the exit code of the git process, and
not the pager.
2. The mingw and regular code are now unified, which makes
the setup_pager function much simpler.
There are two caveats:
1. We used to call execlp directly on the pager, followed
by trying to exec it via the shall. We now just use the
shell (which is what mingw has always done). This may
have different results for pager names which contain
shell metacharacters.
It is also slightly less efficient because we
unnecessarily run the shell; however, pager spawning is
by definition an interactive task, so it shouldn't be
a huge problem.
2. The git process will remain in memory while the user
looks through the pager. This is potentially wasteful.
We could get around this by turning the parent into a
meta-process which spawns _both_ git and the pager,
collects the exit status from git, waits for both to
end, and then exits with git's exit code.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
17 years ago
|
|
|
pager_process.argv = pager_argv;
|
|
|
|
|
pager_process.in = -1;
|
|
|
|
|
#ifndef __MINGW32__
|
|
|
|
|
pager_process.preexec_cb = pager_preexec;
|
|
|
|
|
#endif
|
|
|
|
|
if (start_command(&pager_process))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* original process continues, but writes to the pipe */
|
|
|
|
|
dup2(pager_process.in, 1);
|
|
|
|
|
dup2(pager_process.in, 2);
|
|
|
|
|
close(pager_process.in);
|
|
|
|
|
|
|
|
|
|
/* this makes sure that the parent terminates after the pager */
|
|
|
|
|
atexit(wait_for_pager);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int pager_in_use(void)
|
|
|
|
|
{
|
|
|
|
|
const char *env;
|
|
|
|
|
|
|
|
|
|
if (spawned_pager)
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
|
|
env = getenv("GIT_PAGER_IN_USE");
|
|
|
|
|
return env ? git_config_bool("GIT_PAGER_IN_USE", env) : 0;
|
|
|
|
|
}
|
