Re: [PATCH] bisect: fix replay of CRLF logs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 07, 2020 at 09:29:40PM +0000, Christopher Warrington via GitGitGadget wrote:

> diff --git a/git-bisect.sh b/git-bisect.sh
> index efee12b8b1e..8406a9adc36 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -209,7 +209,11 @@ bisect_replay () {
>  	test "$#" -eq 1 || die "$(gettext "No logfile given")"
>  	test -r "$file" || die "$(eval_gettext "cannot read \$file for replaying")"
>  	git bisect--helper --bisect-reset || exit
> -	while read git bisect command rev
> +
> +	# We remove any CR in the input to handle bisect log files that have
> +	# CRLF line endings. The assumption is that CR within bisect
> +	# commands also don't matter.
> +	tr -d '\r' <"$file" | while read git bisect command rev
>  	do
>  		test "$git $bisect" = "git bisect" || test "$git" = "git-bisect" || continue
>  		if test "$git" = "git-bisect"
> @@ -231,7 +235,9 @@ bisect_replay () {
>  		*)
>  			die "$(gettext "?? what are you talking about?")" ;;
>  		esac
> -	done <"$file"
> +	done

This puts the while-loop on the right-hand side of a pipe, which means
that it's not running in the main shell environment any longer. So any
variables set will be lost after the loop ends, any calls to exit will
only exit the loop and not the whole script, etc.

It looks like we might call into bisect_start inside the loop, which
does exit. I didn't trace all the way through its sub-functions to see
if they set variables.

The simplest fix is probably to clean up "$file" into another tempfile,
and then read from that.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux