Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> writes:
>> 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 <robin.rosenberg@xxxxxxxxxx>
> 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.
> Signed-off-by: Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html