Eric Blake wrote:
> +/usr/local/build/m4/build-i686-gnu-linux/build/project/build/src/.libs/lt-m4:
> copying inserted file: Broken pipe
> +/usr/local/build/m4/build-i686-gnu-linux/build/project/build/src/.libs/lt-m4:
> write error
> | 19. builtins.at:272: 19. divert (builtins.at:272): FAILED
> Ahh. Sounds like a difference in whether SIGPIPE is being ignored in the
> parent shell at the time the test is run.
SIGPIPE! If the python buildbot is inappropriately handling SIGPIPE
that would account for the difference between the automated build and
the interactive builds.
> So should m4 always be verbose about pipe failures when inheriting
> an ignored SIGPIPE from the parent?
I don't think m4 should attempt to workaround a broken environment. I
will research what the buildbot is doing with regards to sigpipe and
report back. If it is broken there then the right answer is to fix it
there.
> I think the following will also work around it for this particular
> test:
>
> input | m4 | { sed 1q; cat >/dev/null; }
>
> so that m4's output is completely consumed, regardless of whether SIGPIPE
> is ignored.
That kind of workaround in a test is fine. But I wouldn't put
anything in the m4 code itself. I think m4 needs to continue to
report write errors correctly.
I am thinking that perhaps a test should determine the state of
sigpipe and report it directly. Then we will know if the build and
test environment is okay or not. If not okay then report the problem
directly so that the environment can be fixed.
Bob
