|
|
|
|
#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"
|
pager: do wait_for_pager on signal death
Since ea27a18 (spawn pager via run_command interface), the
original git process actually does git work, and the pager
is a child process (actually, on Windows it has always been
that way, since Windows lacks fork). After spawning the
pager, we register an atexit() handler that waits for the
pager to finish.
Unfortunately, that handler does not always run. In
particular, if git is killed by a signal, then we exit
immediately. The calling shell then thinks that git is done;
however, the pager is still trying to run and impact the
terminal. The result can be seen by running a long git
process with a pager (e.g., "git log -p") and hitting ^C.
Depending on your config, you should see the shell prompt,
but pressing a key causes the pager to do any terminal
de-initialization sequence.
This patch just intercepts any death-dealing signals and
waits for the pager before dying. Under typical less
configuration, that means hitting ^C will cause git to stop
generating output, but the pager will keep running.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
#include "sigchain.h"
|
|
|
|
|
|
|
|
|
|
#ifndef DEFAULT_PAGER
|
|
|
|
|
#define DEFAULT_PAGER "less"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This is split up from the rest of git so that we can do
|
|
|
|
|
* something different on Windows.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static int spawned_pager;
|
|
|
|
|
|
|
|
|
|
#ifndef WIN32
|
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
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
static const char *pager_argv[] = { 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);
|
|
|
|
|
}
|
|
|
|
|
|
pager: do wait_for_pager on signal death
Since ea27a18 (spawn pager via run_command interface), the
original git process actually does git work, and the pager
is a child process (actually, on Windows it has always been
that way, since Windows lacks fork). After spawning the
pager, we register an atexit() handler that waits for the
pager to finish.
Unfortunately, that handler does not always run. In
particular, if git is killed by a signal, then we exit
immediately. The calling shell then thinks that git is done;
however, the pager is still trying to run and impact the
terminal. The result can be seen by running a long git
process with a pager (e.g., "git log -p") and hitting ^C.
Depending on your config, you should see the shell prompt,
but pressing a key causes the pager to do any terminal
de-initialization sequence.
This patch just intercepts any death-dealing signals and
waits for the pager before dying. Under typical less
configuration, that means hitting ^C will cause git to stop
generating output, but the pager will keep running.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
static void wait_for_pager_signal(int signo)
|
|
|
|
|
{
|
|
|
|
|
wait_for_pager();
|
|
|
|
|
sigchain_pop(signo);
|
|
|
|
|
raise(signo);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *git_pager(void)
|
|
|
|
|
{
|
|
|
|
|
const char *pager;
|
|
|
|
|
|
|
|
|
|
if (!isatty(1))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
pager = getenv("GIT_PAGER");
|
|
|
|
|
if (!pager) {
|
|
|
|
|
if (!pager_program)
|
|
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
pager = pager_program;
|
|
|
|
|
}
|
|
|
|
|
if (!pager)
|
|
|
|
|
pager = getenv("PAGER");
|
|
|
|
|
if (!pager)
|
|
|
|
|
pager = DEFAULT_PAGER;
|
|
|
|
|
else if (!*pager || !strcmp(pager, "cat"))
|
|
|
|
|
pager = NULL;
|
|
|
|
|
|
|
|
|
|
return pager;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void setup_pager(void)
|
|
|
|
|
{
|
|
|
|
|
const char *pager = git_pager();
|
|
|
|
|
|
|
|
|
|
if (!pager)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
spawned_pager = 1; /* means we are emitting to terminal */
|
|
|
|
|
|
|
|
|
|
/* spawn the pager */
|
|
|
|
|
pager_argv[0] = pager;
|
|
|
|
|
pager_process.use_shell = 1;
|
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;
|
|
|
|
|
if (!getenv("LESS")) {
|
|
|
|
|
static const char *env[] = { "LESS=FRSX", NULL };
|
|
|
|
|
pager_process.env = env;
|
|
|
|
|
}
|
|
|
|
|
#ifndef WIN32
|
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.preexec_cb = pager_preexec;
|
|
|
|
|
#endif
|
|
|
|
|
if (start_command(&pager_process))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* original process continues, but writes to the pipe */
|
|
|
|
|
dup2(pager_process.in, 1);
|
|
|
|
|
if (isatty(2))
|
|
|
|
|
dup2(pager_process.in, 2);
|
|
|
|
|
close(pager_process.in);
|
|
|
|
|
|
|
|
|
|
/* this makes sure that the parent terminates after the pager */
|
pager: do wait_for_pager on signal death
Since ea27a18 (spawn pager via run_command interface), the
original git process actually does git work, and the pager
is a child process (actually, on Windows it has always been
that way, since Windows lacks fork). After spawning the
pager, we register an atexit() handler that waits for the
pager to finish.
Unfortunately, that handler does not always run. In
particular, if git is killed by a signal, then we exit
immediately. The calling shell then thinks that git is done;
however, the pager is still trying to run and impact the
terminal. The result can be seen by running a long git
process with a pager (e.g., "git log -p") and hitting ^C.
Depending on your config, you should see the shell prompt,
but pressing a key causes the pager to do any terminal
de-initialization sequence.
This patch just intercepts any death-dealing signals and
waits for the pager before dying. Under typical less
configuration, that means hitting ^C will cause git to stop
generating output, but the pager will keep running.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
16 years ago
|
|
|
sigchain_push_common(wait_for_pager_signal);
|
|
|
|
|
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;
|
|
|
|
|
}
|
