2008-07-25 18:28:41 +02:00
|
|
|
#include "cache.h"
|
2018-08-10 18:51:30 +02:00
|
|
|
#include "config.h"
|
2008-07-25 18:28:41 +02:00
|
|
|
#include "strbuf.h"
|
|
|
|
#include "run-command.h"
|
2012-11-30 23:41:26 +01:00
|
|
|
#include "sigchain.h"
|
2008-07-25 18:28:41 +02:00
|
|
|
|
2009-10-31 02:44:41 +01:00
|
|
|
#ifndef DEFAULT_EDITOR
|
|
|
|
#define DEFAULT_EDITOR "vi"
|
|
|
|
#endif
|
|
|
|
|
2017-11-29 15:37:51 +01:00
|
|
|
int is_terminal_dumb(void)
|
|
|
|
{
|
|
|
|
const char *terminal = getenv("TERM");
|
|
|
|
return !terminal || !strcmp(terminal, "dumb");
|
|
|
|
}
|
|
|
|
|
2009-11-12 01:01:27 +01:00
|
|
|
const char *git_editor(void)
|
2008-07-25 18:28:41 +02:00
|
|
|
{
|
Do not use VISUAL editor on dumb terminals
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:56:07 +01:00
|
|
|
const char *editor = getenv("GIT_EDITOR");
|
2017-11-29 15:37:51 +01:00
|
|
|
int terminal_is_dumb = is_terminal_dumb();
|
2008-07-25 18:28:41 +02:00
|
|
|
|
|
|
|
if (!editor && editor_program)
|
|
|
|
editor = editor_program;
|
Do not use VISUAL editor on dumb terminals
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:56:07 +01:00
|
|
|
if (!editor && !terminal_is_dumb)
|
2008-07-25 18:28:41 +02:00
|
|
|
editor = getenv("VISUAL");
|
|
|
|
if (!editor)
|
|
|
|
editor = getenv("EDITOR");
|
|
|
|
|
Do not use VISUAL editor on dumb terminals
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-12 00:56:07 +01:00
|
|
|
if (!editor && terminal_is_dumb)
|
2009-11-12 01:01:27 +01:00
|
|
|
return NULL;
|
2008-07-25 18:28:41 +02:00
|
|
|
|
|
|
|
if (!editor)
|
2009-10-31 02:44:41 +01:00
|
|
|
editor = DEFAULT_EDITOR;
|
2008-07-25 18:28:41 +02:00
|
|
|
|
2009-11-12 01:01:27 +01:00
|
|
|
return editor;
|
|
|
|
}
|
|
|
|
|
2018-08-10 18:51:30 +02:00
|
|
|
const char *git_sequence_editor(void)
|
2009-11-12 01:01:27 +01:00
|
|
|
{
|
2018-08-10 18:51:30 +02:00
|
|
|
const char *editor = getenv("GIT_SEQUENCE_EDITOR");
|
|
|
|
|
|
|
|
if (!editor)
|
|
|
|
git_config_get_string_const("sequence.editor", &editor);
|
|
|
|
if (!editor)
|
|
|
|
editor = git_editor();
|
2009-11-12 01:01:27 +01:00
|
|
|
|
2018-08-10 18:51:30 +02:00
|
|
|
return editor;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int launch_specified_editor(const char *editor, const char *path,
|
|
|
|
struct strbuf *buffer, const char *const *env)
|
|
|
|
{
|
2009-11-12 01:01:27 +01:00
|
|
|
if (!editor)
|
|
|
|
return error("Terminal is dumb, but EDITOR unset");
|
|
|
|
|
2008-07-25 18:28:41 +02:00
|
|
|
if (strcmp(editor, ":")) {
|
2013-07-28 18:59:42 +02:00
|
|
|
const char *args[] = { editor, real_path(path), NULL };
|
2014-08-19 21:09:35 +02:00
|
|
|
struct child_process p = CHILD_PROCESS_INIT;
|
launch_editor: propagate signals from editor to git
We block SIGINT and SIGQUIT while the editor runs so that
git is not killed accidentally by a stray "^C" meant for the
editor or its subprocesses. This works because most editors
ignore SIGINT.
However, some editor wrappers, like emacsclient, expect to
die due to ^C. We detect the signal death in the editor and
properly exit, but not before writing a useless error
message to stderr. Instead, let's notice when the editor was
killed by a terminal signal and just raise the signal on
ourselves. This skips the message and looks to our parent
like we received SIGINT ourselves.
The end effect is that if the user's editor ignores SIGINT,
we will, too. And if it does not, then we will behave as if
we did not ignore it. That should make all users happy.
Note that in the off chance that another part of git has
ignored SIGINT while calling launch_editor, we will still
properly detect and propagate the failed return code from
the editor (i.e., the worst case is that we generate the
useless error, not fail to notice the editor's death).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-30 23:41:50 +01:00
|
|
|
int ret, sig;
|
2017-12-07 16:16:41 +01:00
|
|
|
int print_waiting_for_editor = advice_waiting_for_editor && isatty(2);
|
|
|
|
|
|
|
|
if (print_waiting_for_editor) {
|
|
|
|
/*
|
|
|
|
* A dumb terminal cannot erase the line later on. Add a
|
|
|
|
* newline to separate the hint from subsequent output.
|
|
|
|
*
|
|
|
|
* Make sure that our message is separated with a whitespace
|
|
|
|
* from further cruft that may be written by the editor.
|
|
|
|
*/
|
|
|
|
const char term = is_terminal_dumb() ? '\n' : ' ';
|
|
|
|
|
|
|
|
fprintf(stderr,
|
|
|
|
_("hint: Waiting for your editor to close the file...%c"),
|
|
|
|
term);
|
|
|
|
fflush(stderr);
|
|
|
|
}
|
2008-07-25 18:28:41 +02:00
|
|
|
|
2012-11-30 23:41:04 +01:00
|
|
|
p.argv = args;
|
|
|
|
p.env = env;
|
|
|
|
p.use_shell = 1;
|
2019-02-22 23:25:04 +01:00
|
|
|
p.trace2_child_class = "editor";
|
2012-11-30 23:41:04 +01:00
|
|
|
if (start_command(&p) < 0)
|
|
|
|
return error("unable to start editor '%s'", editor);
|
|
|
|
|
2012-11-30 23:41:26 +01:00
|
|
|
sigchain_push(SIGINT, SIG_IGN);
|
|
|
|
sigchain_push(SIGQUIT, SIG_IGN);
|
|
|
|
ret = finish_command(&p);
|
run-command: encode signal death as a positive integer
When a sub-command dies due to a signal, we encode the
signal number into the numeric exit status as "signal -
128". This is easy to identify (versus a regular positive
error code), and when cast to an unsigned integer (e.g., by
feeding it to exit), matches what a POSIX shell would return
when reporting a signal death in $? or through its own exit
code.
So we have a negative value inside the code, but once it
passes across an exit() barrier, it looks positive (and any
code we receive from a sub-shell will have the positive
form). E.g., death by SIGPIPE (signal 13) will look like
-115 to us in inside git, but will end up as 141 when we
call exit() with it. And a program killed by SIGPIPE but run
via the shell will come to us with an exit code of 141.
Unfortunately, this means that when the "use_shell" option
is set, we need to be on the lookout for _both_ forms. We
might or might not have actually invoked the shell (because
we optimize out some useless shell calls). If we didn't invoke
the shell, we will will see the sub-process's signal death
directly, and run-command converts it into a negative value.
But if we did invoke the shell, we will see the shell's
128+signal exit status. To be thorough, we would need to
check both, or cast the value to an unsigned char (after
checking that it is not -1, which is a magic error value).
Fortunately, most callsites do not care at all whether the
exit was from a code or from a signal; they merely check for
a non-zero status, and sometimes propagate the error via
exit(). But for the callers that do care, we can make life
slightly easier by just using the consistent positive form.
This actually fixes two minor bugs:
1. In launch_editor, we check whether the editor died from
SIGINT or SIGQUIT. But we checked only the negative
form, meaning that we would fail to notice a signal
death exit code which was propagated through the shell.
2. In handle_alias, we assume that a negative return value
from run_command means that errno tells us something
interesting (like a fork failure, or ENOENT).
Otherwise, we simply propagate the exit code. Negative
signal death codes confuse us, and we print a useless
"unable to run alias 'foo': Success" message. By
encoding signal deaths using the positive form, the
existing code just propagates it as it would a normal
non-zero exit code.
The downside is that callers of run_command can no longer
differentiate between a signal received directly by the
sub-process, and one propagated. However, no caller
currently cares, and since we already optimize out some
calls to the shell under the hood, that distinction is not
something that should be relied upon by callers.
Fix the same logic in t/test-terminal.perl for consistency [jc:
raised by Jonathan in the discussion].
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-05 15:49:49 +01:00
|
|
|
sig = ret - 128;
|
2012-11-30 23:41:26 +01:00
|
|
|
sigchain_pop(SIGINT);
|
|
|
|
sigchain_pop(SIGQUIT);
|
launch_editor: propagate signals from editor to git
We block SIGINT and SIGQUIT while the editor runs so that
git is not killed accidentally by a stray "^C" meant for the
editor or its subprocesses. This works because most editors
ignore SIGINT.
However, some editor wrappers, like emacsclient, expect to
die due to ^C. We detect the signal death in the editor and
properly exit, but not before writing a useless error
message to stderr. Instead, let's notice when the editor was
killed by a terminal signal and just raise the signal on
ourselves. This skips the message and looks to our parent
like we received SIGINT ourselves.
The end effect is that if the user's editor ignores SIGINT,
we will, too. And if it does not, then we will behave as if
we did not ignore it. That should make all users happy.
Note that in the off chance that another part of git has
ignored SIGINT while calling launch_editor, we will still
properly detect and propagate the failed return code from
the editor (i.e., the worst case is that we generate the
useless error, not fail to notice the editor's death).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-30 23:41:50 +01:00
|
|
|
if (sig == SIGINT || sig == SIGQUIT)
|
|
|
|
raise(sig);
|
2012-11-30 23:41:26 +01:00
|
|
|
if (ret)
|
2008-07-25 18:28:42 +02:00
|
|
|
return error("There was a problem with the editor '%s'.",
|
|
|
|
editor);
|
2017-12-07 16:16:41 +01:00
|
|
|
|
|
|
|
if (print_waiting_for_editor && !is_terminal_dumb())
|
|
|
|
/*
|
pager: add a helper function to clear the last line in the terminal
There are a couple of places where we want to clear the last line on
the terminal, e.g. when a progress bar line is overwritten by a
shorter line, then the end of that progress line would remain visible,
unless we cover it up.
In 'progress.c' we did this by always appending a fixed number of
space characters to the next line (even if it was not shorter than the
previous), but as it turned out that fixed number was not quite large
enough, see the fix in 9f1fd84e15 (progress: clear previous progress
update dynamically, 2019-04-12). From then on we've been keeping
track of the length of the last displayed progress line and appending
the appropriate number of space characters to the next line, if
necessary, but, alas, this approach turned out to be error prone, see
the fix in 1aed1a5f25 (progress: avoid empty line when breaking the
progress line, 2019-05-19). The next patch in this series is about to
fix a case where we don't clear the last line, and on occasion do end
up with such garbage at the end of the line. It would be great if we
could do that without the need to deal with that without meticulously
computing the necessary number of space characters.
So add a helper function to clear the last line on the terminal using
an ANSI escape sequence, which has the advantage to clear the whole
line no matter how wide it is, even after the terminal width changed.
Such an escape sequence is not available on dumb terminals, though, so
in that case fall back to simply print a whole terminal width (as
reported by term_columns()) worth of space characters.
In 'editor.c' launch_specified_editor() already used this ANSI escape
sequence, so replace it with a call to this function.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24 20:13:16 +02:00
|
|
|
* Erase the entire line to avoid wasting the
|
|
|
|
* vertical space.
|
2017-12-07 16:16:41 +01:00
|
|
|
*/
|
pager: add a helper function to clear the last line in the terminal
There are a couple of places where we want to clear the last line on
the terminal, e.g. when a progress bar line is overwritten by a
shorter line, then the end of that progress line would remain visible,
unless we cover it up.
In 'progress.c' we did this by always appending a fixed number of
space characters to the next line (even if it was not shorter than the
previous), but as it turned out that fixed number was not quite large
enough, see the fix in 9f1fd84e15 (progress: clear previous progress
update dynamically, 2019-04-12). From then on we've been keeping
track of the length of the last displayed progress line and appending
the appropriate number of space characters to the next line, if
necessary, but, alas, this approach turned out to be error prone, see
the fix in 1aed1a5f25 (progress: avoid empty line when breaking the
progress line, 2019-05-19). The next patch in this series is about to
fix a case where we don't clear the last line, and on occasion do end
up with such garbage at the end of the line. It would be great if we
could do that without the need to deal with that without meticulously
computing the necessary number of space characters.
So add a helper function to clear the last line on the terminal using
an ANSI escape sequence, which has the advantage to clear the whole
line no matter how wide it is, even after the terminal width changed.
Such an escape sequence is not available on dumb terminals, though, so
in that case fall back to simply print a whole terminal width (as
reported by term_columns()) worth of space characters.
In 'editor.c' launch_specified_editor() already used this ANSI escape
sequence, so replace it with a call to this function.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-24 20:13:16 +02:00
|
|
|
term_clear_line();
|
2008-07-25 18:28:41 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!buffer)
|
2008-07-25 18:28:42 +02:00
|
|
|
return 0;
|
2008-07-25 18:28:41 +02:00
|
|
|
if (strbuf_read_file(buffer, path, 0) < 0)
|
2016-05-08 11:47:43 +02:00
|
|
|
return error_errno("could not read file '%s'", path);
|
2008-07-25 18:28:42 +02:00
|
|
|
return 0;
|
2008-07-25 18:28:41 +02:00
|
|
|
}
|
2018-08-10 18:51:30 +02:00
|
|
|
|
|
|
|
int launch_editor(const char *path, struct strbuf *buffer, const char *const *env)
|
|
|
|
{
|
|
|
|
return launch_specified_editor(git_editor(), path, buffer, env);
|
|
|
|
}
|
|
|
|
|
|
|
|
int launch_sequence_editor(const char *path, struct strbuf *buffer,
|
|
|
|
const char *const *env)
|
|
|
|
{
|
|
|
|
return launch_specified_editor(git_sequence_editor(), path, buffer, env);
|
|
|
|
}
|