Re: [PATCH] Abort mergetool on read error from stdinput
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:10
Robin Rosenberg [off-list ref] writes:
quoted
What platform are you on? ^C kills the entire process group here.Here is a better version and motivation. -- robin From 3aa3793a4d1dff940ca6b698a9c01a1fc9bdb9b3 Mon Sep 17 00:00:00 2001 From: Robin Rosenberg <redacted> Date: Fri, 3 Dec 2010 09:23:23 +0100 Subject: [PATCH] Abort mergetool on read error from stdinput If the mergetool has not quit (by mistake like pressing Command-W instead of Command-Q) and the user pressed Ctrl-C in the shell that runs mergetool, bash goes into an infinite look, at least on Mac OS X. Ctrl-C kills the diff program but not the mergetool script.
Interesting. Perhaps the way the script is spawned need to be improved so that \C-c will do the right thing to avoid this infinite "loop"? Is "exit 1" the best thing to do here? Doesn't the caller of this function (or the caller of that caller) want to perform some clean-up action depending on the answer that comes back from it? What I am wondering is if it would futureproof us better to set $status to an appropriate value and break out of the loop, pretending that the end user gave a reasonable answer (probably "n" but I am just guessing) to "read answer", instead of dying.
quoted hunk
Signed-off-by: Robin Rosenberg <redacted> --- git-mergetool--lib.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh index 77d4aee..1d1413d 100644 --- a/git-mergetool--lib.sh +++ b/git-mergetool--lib.sh@@ -35,7 +35,7 @@ check_unchanged () { while true; do echo "$MERGED seems unchanged." printf "Was the merge successful? [y/n] " - read answer + read answer || exit 1 case "$answer" in y*|Y*) status=0; break ;; n*|N*) status=1; break ;;-- 1.7.3.2.452.gb3012.dirty