quilt-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Quilt-dev] [patch 2/8]


From: Andreas Gruenbacher
Subject: Re: [Quilt-dev] [patch 2/8]
Date: Wed, 14 Sep 2005 15:05:41 +0200
User-agent: KMail/1.8

On Wednesday 14 September 2005 13:51, Gary V. Vaughan wrote:
> Agreed.  But it is common practice to work around bugs in tools you
> depend on if they have a significant installed base...

The patch doesn't really fix anything: stderr is not connected to a pipe here. 
Probably timing changes slightly so that SIGPIPE doesn't trigger anymore in 
this particular case; it may well trigger with a different version of bash, 
etc.

The broken pipe bugs trigger differently with different versions of bash if 
bash is compiled without DONT_REPORT_SIGPIPE (see config-top.h in the bash 
sources). I don't have a reliable test that would always produce the error.

> > Redirecting stderr to /dev/null is not an acceptable solution, sorry.
>
> Why not?
>
> There must be a middle ground between expecting a significant proportion
> of the installed user base to compile a special bash just for quilt at
> one extreme, and have them put up with spurious error messages at the
> other?

IMHO, bash without DONT_REPORT_SIGPIPE is pretty useless.

> > See my post on this topic 4 months ago:
> > http://lists.gnu.org/archive/html/quilt-dev/2005-05/msg00031.html
> > It got no answer unfortunately.
>
> Easy test: $ cvs diff | (exit 1)

Sometimes, yes. We cannot use that in configure.ac, either.

> > The only thing we can do is probably to document the problem, and ask
> > remaining distributions (Linux or not) to apply the patch fixing the
> > problem when building their bash package. Maybe then the bash folks will
> > finally agree that this should be made the default.
>
> So when bash 3.1 comes out in 2007, and vendors release OSes that adopt
> it 6 months later, it might reach widespread in about 3 or 4 years.
> I still think a user friendly work around until then is perfectly
> reasonable!

I don't know a real workaround. ``bash --noprofile --norc -i'' seems to behave 
well in all cases I found, but that's hardly acceptable.

-- Andreas.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]