threads / patch / 25923

patchAbort mergetool on read error from stdinput

Subject: [PATCH] Abort mergetool on read error from stdinput

## tl;dr

5 messages between Dec 2, 2010 and Dec 3, 2010. Diffs are folded; open one to read it.

replies: 4people: 3as markdown or json

Robin Rosenberg· Dec 2, 2010, 06:28 UTC · lore

If you press e.g Ctrl-C the interactive merge goes into an infinite loop that is somewhat tricky to stop. Abort the script if bash read fails.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
 git-mergetool--lib.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Show changes to git-mergetool--lib.sh +1 −1

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 77d4aee..2fc2886 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 < /dev/tty || exit 1
 			case "$answer" in
 			y*|Y*) status=0; break ;;
 			n*|N*) status=1; break ;;

-- 
1.7.2.3

Jonathan Nieder· Dec 2, 2010, 06:38 UTC · re: Robin Rosenberg · lore

Re: [PATCH] Abort mergetool on read error from stdinput

Hi Robin,

Robin Rosenberg wrote:

> infinite loop that is somewhat tricky to stop. Abort the script
> if bash read fails.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

That motivates half the change.

Show 8 quoted lines

> --- 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 < /dev/tty || exit 1

Why not
			read answer || exit 1

so tests can still run without blocking? Aside from that, this looks like a good change; thanks.

What platform are you on?  ^C kills the entire process group here.

Robin Rosenberg· Dec 3, 2010, 09:05 UTC · re: Jonathan Nieder · lore

Re: [PATCH] Abort mergetool on read error from stdinput

2 dec 2010 kl. 07:38 skrev Jonathan Nieder:

Show 27 quoted lines

> Hi Robin,
> 
> Robin Rosenberg wrote:
> 
>> infinite loop that is somewhat tricky to stop. Abort the script
>> if bash read fails.
>> 
>> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> 
> That motivates half the change.
> 
>> --- 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 < /dev/tty || exit 1
> 
> Why not
> 			read answer || exit 1
> 
> so tests can still run without blocking?  Aside from that, this looks
> like a good change; thanks.
> 
> 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@dewire.com>
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.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
 git-mergetool--lib.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Show changes to git-mergetool--lib.sh +1 −1

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

Jonathan Nieder· Dec 3, 2010, 09:14 UTC · re: Robin Rosenberg · lore

Re: [PATCH] Abort mergetool on read error from stdinput

Robin Rosenberg wrote:

Show 26 quoted lines

> 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.
> 
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
>  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 ;;

> Here is a better version and motivation.

Thanks.  For what it's worth,
Acked-by: Jonathan Nieder <jrnieder@gmail.com>

Junio C Hamano· Dec 3, 2010, 19:45 UTC · re: Robin Rosenberg · lore

Re: [PATCH] Abort mergetool on read error from stdinput

Robin Rosenberg <robin.rosenberg@dewire.com> writes:

Show 16 quoted lines

>> 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@dewire.com>
> 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.

Show 20 quoted lines

> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
>  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