Re: Bug report : bad filter-branch (OSX only)

From: Jeff King <peff@peff.net>
Date: Apr 29, 2015, 16:43 UTC
Message-ID: <20150429164315.GA26682@peff.net>
In-Reply-To: <xmqqioce6gon.fsf@gitster.dls.corp.google.com>

On Wed, Apr 29, 2015 at 09:30:00AM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> >> (
> >> 	while read x && test -n "$x"
> >>         do
> >>         	:;
> >> 	done
> >> 	cat
> >> ) <../commit | eval "$filter_msg"
> >> 
> >> would not spin too much in shell loop, perhaps?
> >
> > Yeah, that is not too bad. Probably we want "read -r", just in case of
> > weirdness in the header lines (and that's in POSIX, and we use it
> > in other scripts, so it should be portable enough). And we can save a
> > subshell if we don't mind the potential variable-name conflict.
> 
> As all we care about is "have we hit an empty line", I do not think "-r"
> really matters, but it would not hurt.

I think something like:

  author ...
  committer ...
  encoding foo\

  this is the real commit message

would behave incorrectly without "-r". I would be shocked if that ever happens in real life, but I think it doesn't hurt to be careful.

> As to s/()/{}/, please tell me what I am doing wrong.  I am getting
> the same process IDs from all of the $$s and the only difference
> seems to be variable clobbering.

$$ is always the pid of the main shell process, even in a subshell. If your shell is bash, it provides $BASHPID which can tell the difference (if you put $BASHPID in your test script, it does show that we fork for the subshell).

On Linux, you can also test with "strace -fce clone". Interestingly, dash produces one fewer fork than bash on your test script, but I didn't track down the exact difference. But I can imagine a shell that is smart enough to realize a fork is not required in this instance.

-Peff