git/editor.c, branch v2.18.2

launch_editor(): indicate that Git waits for user input

2017-12-07T18:10:19Z

When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user might be left staring at the original Git terminal window without even realizing that s/he needs to interact with another window before Git can proceed. To this user Git appears hanging. Print a message that Git is waiting for editor input in the original terminal and get rid of it when the editor returns, if the terminal supports erasing the last line. Also, make sure that our message is terminated with a whitespace so that any message the editor may show upon starting up will be kept separate from our message. Power users might not want to see this message or their editor might already print such a message (e.g. emacsclient). Allow these users to suppress the message by disabling the "advice.waitingForEditor" config. The standard advise() function is not used here as it would always add a newline which would make deleting the message harder. Helped-by: Junio C Hamano Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

refactor "dumb" terminal determination

2017-12-04T17:38:30Z

Move the code to detect "dumb" terminals into a single location. This avoids duplicating the terminal detection code yet again in a subsequent commit. Signed-off-by: Lars Schneider Signed-off-by: Junio C Hamano

editor.c: use error_errno()

2016-05-09T19:29:08Z

Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

run-command: introduce CHILD_PROCESS_INIT

2014-08-20T16:53:37Z

Most struct child_process variables are cleared using memset first after declaration. Provide a macro, CHILD_PROCESS_INIT, that can be used to initialize them statically instead. That's shorter, doesn't require a function call and is slightly more readable (especially given that we already have STRBUF_INIT, ARGV_ARRAY_INIT etc.). Helped-by: Johannes Sixt Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

editor: use canonicalized absolute path

2013-07-29T19:15:27Z

By improving the relative_path() algorithm, e02ca72 (path.c: refactor relative_path(), not only strip prefix, 2013-06-25) uncovered a latent bug in Emacs. While most editor applications like cat and vim handle non-canonicalized relative paths fine, emacs does not. This is due to a long-standing bug in emacs, where it refuses to resolve symlinks in the supplied path: #!/bin/sh cd /tmp mkdir z z/a z/b echo moodle >z/a/file ln -s z/b cd b emacs ../a/file # fail: attempts to open /tmp/a/file Even if emacs were to be patched to fix this bug, it may be nicer to help users running older versions. Note that this can potentially regress for users of all editors, when they ask "what file am I editing?" to the editor, as it is likely to answer with an unsightly long full path. Co-authored-by: Nguyễn Thái Ngọc Duy Signed-off-by: Ramkumar Ramachandra Signed-off-by: Junio C Hamano

run-command: encode signal death as a positive integer

2013-01-06T19:09:18Z

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 Acked-by: Johannes Sixt Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

launch_editor: propagate signals from editor to git

2012-12-02T10:07:08Z

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 Signed-off-by: Junio C Hamano

launch_editor: ignore terminal signals while editor has control

2012-12-02T10:06:04Z

The user's editor likely catches SIGINT (ctrl-C). but if the user spawns a command from the editor and uses ctrl-C to kill that command, the SIGINT will likely also kill git itself (depending on the editor, this can leave the terminal in an unusable state). Let's ignore it while the editor is running, and do the same for SIGQUIT, which many editors also ignore. This matches the behavior if we were to use system(3) instead of run-command. Signed-off-by: Paul Fox Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

launch_editor: refactor to use start/finish_command

2012-12-02T10:05:41Z

The launch_editor function uses the convenient run_command_* interface. Let's use the more flexible start_command and finish_command functions, which will let us manipulate the parent state while we're waiting for the child to finish. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

editor: use run_command's shell feature

2010-01-06T07:41:51Z

Now that run_command implements the same code in a more general form, we can make use of it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano