bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib-tool should be interruptible


From: Ralf Wildenhues
Subject: Re: gnulib-tool should be interruptible
Date: Wed, 20 Sep 2006 21:43:45 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

[ Behdad, this is:
http://lists.gnu.org/archive/html/bug-gnulib/2006-09/msg00221.html ]

Hello Paul,

* Paul Eggert wrote on Tue, Sep 19, 2006 at 06:10:07PM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> >     * gnulib-tool (func_version): Create output all at once, to
> >     avoid triggering unnecessary SIGPIPEs.
> 
> gnulib-tool doesn't trap SIGPIPE before invoking that code, so you
> must be worried about the case where the caller traps SIGPIPE?

Hmm, actually I have no idea whether that was the case with the bug
reported against libtool.  Behdad, does tinderbox trap SIGPIPE?

> That doesn't sound like much of a real problem, but if it is, this
> looks to me like a band-aid that doesn't solve things; it'd cut down
> the number of bogus messages without eliminating them.

This I don't understand.  If I do the output with one `echo', with sane
shells that will cause exactly one `write', which, when piped to a
  head -n 1

will succeed: at least some of the data will be written (in this case,
since it's a write to a pipe and the amount of data is typically smaller
than PIPE_BUF, all should be written, right?).  Hmm, it seems that POSIX
doesn't even specify when `echo' will fail.  But still, I don't follow
why there should be `broken pipe' messages in this case.

> That being said, I don't see why the patch would hurt, so it's fine
> with me if you install it.

Will do, thanks.  I'm merely pondering whether to make the ChangeLog
entry read
        * gnulib-tool (func_version): Create output all at once, to
        avoid triggering unnecessary SIGPIPEs, in case the caller traps
        it.
or
        * gnulib-tool (func_version): Create output all at once.
:-)

Cheers, and thanks for being patient with me,
Ralf




reply via email to

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