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.