On 9/14/05, Gary V. Vaughan <[EMAIL PROTECTED]> wrote:
> John Vandenberg wrote:
> > On 9/14/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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
_______________________________________________
Quilt-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/quilt-dev
