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

[Gary V. Vaughan]

Hi Jean, John,

Jean Delvare wrote:

[Gary V. Vaughan]

This does (I think there needs to be a separate long running non-shell
process generating the output):

$ cvs diff | (exit 1)

Unfortunately this is not a portable test (you need to be in a CVS
repository.)

Indeed, I was just looking for a quick way to see whether one is running
a shell that has the bug.

This seems to work for me:
cat /dev/zero | true

I don't see a pipe error when I do this.

Note that your "cvs diff" example above is interesting by itself. I
quite frequently run "cvs diff | less" and happened to get "Broken
pipe" error messages when quitting less before hitting the bottom of
the file. Obviously, now that I recompiled bash with the fix, it
doesn't show anymore. This clearly demonstrates that the problem is
with bash in the first place, and several other applications or use
cases are affected, not just quilt, so there's nothing to be fixed on
our side.

I agree whole-heartedly that the bug is the fault of bash.  And I
concede that distribution vendors can work around it for the sake
of quilt by compiling the bash they ship with appropriate options.
However, I think it hurts quilt to see a spurious error message or
two part way through some of the commands it is running... it's only
because I recognised the error that I didn't give up on quilt as
being low quality when it started doing this for me.

I think there are two good approaches to saving face with users
here:

  1. Workaround the known bash bug in applications built on bash.
  2. Have configure choke and give explicit instructions on where
     to get and how to compile and install a fresh bash that doesn't
     exhibit the bug.

Anything else is just passing the buck IMHO.

Unfortunately, I can't come up with a reliable test case for whether
bash has the problem :-(

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.

At least Red Hat/Fedora and Debian enable that compile time option.
Gentoo did not the last time I checked but I would be very surprised if
they don't change their mind soon. Slackware doesn't have the option
and (unfortunately) I don't expect them to change. Can't remember
which of Mandriva and SuSE has it, I'll check again. The bottom line is
that 3 out of 6 major Linux distributions already use the compile time
option. I still need to check *BSD.

Bash is installed as a binary package in very many more places than just

and it's where a big portion of quilt's potential user base live.

a handful of Linux distributors who happen to have got it right. *Those* installations won't be kept up to date as well as even debian,

To me the solution is quite simple. Any distribution providing a bash
package and a quilt package have to enable the compile time option. If
they don't, this is a distribution bug and they have to fix it. For
other users, they have to install quilt by themselves already, so
installing bash shouldn't be a problem.

Any we can help the distributions do that by having the quilt build
tell them what is wrong with bash and how to fix it.

 {
        @AWK@ '
        $1 == "***" || $1 == "---" \
-               { exit }
+               { stop=1 }
+       stop    { next }

I don't buy this, sorry. This hurts readability and performance. And we
would need to do this in several places. And we would then have a hard
time remembering that some constructs should be avoided in later
additions to quilt. So let's just not do it.

Okay.  Was just a thought :-D  I have compiled

If you really want things to improve, you should:
* Ask your distribution to enable the compile time option in their bash
package (unless they already do it.)
* Ask the bash people to change their mind and at least make it a runtime
option, if not the default.
If enough people ask for this, it might happen.

build.  We should really try to work around the bug *now*.

Cheers,
        Gary.
--
Gary V. Vaughan      ())_.  [EMAIL PROTECTED],gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Maybe. Eventually. But it will be literally *years* before any significant proportion of bash users are running that hypothetical

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Quilt-dev mailing list
Quilt-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/quilt-dev