[Top][All Lists]
[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