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

[Jeff King <peff@peff.net>]

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

> >> (
> >> 	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