Re: [Quilt-dev] workaround "received broken pipe signal" bash bug (was [patch 2/8])

[John Vandenberg]

On 9/14/05, Gary V. Vaughan <address@hidden> wrote:
> John Vandenberg wrote:
> > On 9/14/05, address@hidden <address@hidden> wrote:
> >
> >>Unless compiled specially just to avoid it, bash gives an occasional
> >>disconcerting (but spurious) warning when a process at the receiving
> >>side of a shell pipe closes before the sender has flushed all of its
> >>data.  `quilt refresh' is particularly prone.
> >>
> >>This patch simply redirects stderr to /dev/null in the one instance
> >>that seems to be the root of the problem, and thus saves the bother
> >>of recompiling bash.
> >
> >
> > Gary,
> >
> > I haven't noticed this problem on OS X 10.3.2, using bash 2.05b.0(1).
> > If I understand correctly, the following simple case should
> > demonstrate the problem?
> >
> > $ (echo foo; i=1; for ((i = 0; i < 100; i++)); do sleep 1; done) | awk
> > '{ exit }'
> 
> Nope, this doesn't error out on Apple's bash.
> 
> This does (I think there needs to be a separate long running non-shell
> process generating the output):
> 
> $ cvs diff | (exit 1)

afaics, there are probably many, many instances of this problem; I
suggest that the first step is to find the extent of the problem
before updating quilt; it may be impractical to fix this
incompatibility, and it will certainly be better to have 99% of the
instances collated into a single patch.

Have you tried the bash from fink ?

> > If not, could you provide a more complicated case that does cause
> > report the error, as I would like to see the problem here, or know
> > what is different.

It would be helpful if we can come up with a standalone command line
that demonstrates the problem.  While using cvs may demonstrate that a
problem exists, it is not reproducible, as it depends on the contents
of a cvs repository.

> There is a compile time option to bash (DONT_REPORT_SIGPIPE) which
> turns off the error message, but it is not part of the default build,
> so many vendor supplied and self built bash installations exhibit the
> problem.
> 
> > If there is such a fundamental problem with bash on 10.4.2, a
> > configure test to reject that build of bash would be a simpler fix.
> 
> It's not just Apple's bash :-(  Here is a different workaround that
> might be less contentious (my mailer will almost certainly wrap long
> lines, so you'll need to apply by hand):

A configure test can be written to reject any bash on any platform
that exhibits this behaviour, provided we can isolate what causes the
problem.
--
John