Bruno Haible <br...@clisp.org> wrote:
>> ./bootstrap: Copying ._bootmp/gnulib-tests/Makefile.am to
>> gnulib-tests/gnulib.mk...
>> -sed: couldn't write 60 items to stdout: Broken pipe
>> +sed: couldn't write 56 items to stdout: Broken pipe
>>
>> I see that it's technically harmless and comes from here:
>>
>> sed "$remove_intl" $1/$dir/$file | cmp -s - $dir/$gnulib_mk || {
>> echo "$0: Copying $1/$dir/$file to $dir/$gnulib_mk ..." &&
>>
>> because using GNU cmp's -s (--silent/ exit-status-only) option
>> makes it refrain from reading all input, so sed's write evokes SIGPIPE.
>>
>> I may take this as encouragement not to use -s,
>> and just redirect to /dev/null instead.
>
> The purpose of SIGPIPE is to speed up pipes of commands. By piping
> cmp's result to /dev/null you renounce this optimization. In order to
> exploit this optimization, without getting bash's error message, all
> you need is func_reset_sigpipe from gnulib-tool, and
>
> (func_reset_sigpipe
> sed "$remove_intl" $1/$dir/$file | cmp -s - $dir/$gnulib_mk || {
> echo "$0: Copying $1/$dir/$file to $dir/$gnulib_mk ..." && ...
> } )
Hi Bruno,
Thanks, but this is independent of which shell I use.
(the diagnostic doesn't come from bash)
I.e., I can reproduce it with zsh:
$ seq 1000000|sed s/1/2/|cmp -s - /dev/null
sed: couldn't write 4 items to stdout: Broken pipe
seq: write error: Broken pipe
Also, even if I do reset the shell's sigpipe handler,
it doesn't change the fact that sed complains:
$ (trap - SIGPIPE; seq 1000000|sed s/1/2/|cmp -s - /dev/null )
sed: couldn't write 4 items to stdout: Broken pipe
[Exit 1]
Besides, avoiding the failure/diagnostic is more important
to me than getting better performance from two cmp uses.
