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