Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: ... >> s/is/may be/ >> Early reader termination may still deserve a diagnostic. >> Or it could be that POSIX requires the application to diagnose EPIPE, >> regardless ;-) > > I disagree here. If early reader termination leads to a diagno

Re: tee logs no output if stdout is closed

After the newest changes to gnulib, here's a revised version of the patch proposed in From a4434d71a1a3ec7a6aee6de4a81da36301b12a28 Mon Sep 17 00:00:00 2001 From: Bruno Haible <[EMAIL PROTECTED]> Date: Mon, 6 Oct 2008 02:58:5

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > Thanks for writing all that. The code looks fine. Glad to see that our disagreements have been reduced to the comments. > Let's not use "signaled" here. Yes, indeed this term is confusing in a paragraph dealing with signals. > How about this in place of the above: > > /

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > You can distinguish close_stream and close_stdout. close_stream is library >> > code, >> > close_stdout is not. What about a 'bool ignore_epipe' that influences the >> > behaviour of close_stdout? Whereas the library code that cal

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > > You can distinguish close_stream and close_stdout. close_stream is library > > code, > > close_stdout is not. What about a 'bool ignore_epipe' that influences the > > behaviour of close_stdout? Whereas the library code that called close_stream > > has to check against EOF/E

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > ... if SIGPIPE is blocked or ignored. >> > >> >> which is not generally recommended. >> >> In some contexts. Some environments (mis-configured login/csh) have >> resulted in the default SIGPIPE handler being SIG_IGN. > > I agree t

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> What else do you propose to cover these cases, if not a global variable? > > If only one behavior is needed across an entire package, a dummy module > with gl_MODULE_INDICATOR would do. Better than having fwriteerror do > one thing and close_stdout do a

Re: tee logs no output if stdout is closed

Paolo Bonzini wrote: > > To make it clear: > > - Patch 1 only - applies if close_stdout were modified to ignore EPIPE > > always (which Jim has rejected). > > - Patch 1 + 2 combined - applies if close_stdout is as it currently is. > > What's wrong in having patch 1 + 2 combined with close_

Re: tee logs no output if stdout is closed

> What else do you propose to cover these cases, if not a global variable? If only one behavior is needed across an entire package, a dummy module with gl_MODULE_INDICATOR would do. Better than having fwriteerror do one thing and close_stdout do another. Paolo

Re: tee logs no output if stdout is closed

Paolo Bonzini wrote: > > If you want both scenarios - the "don't know which of the two terminates > > first" > > and the "writer must terminate first" - to be supported by close_stream and > > close_stdout, IMO the program needs to be able to tell these functions about > > it, probably through a g

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > > ... if SIGPIPE is blocked or ignored. > > > >> which is not generally recommended. > > In some contexts. Some environments (mis-configured login/csh) have > resulted in the default SIGPIPE handler being SIG_IGN. I agree that having SIGPIPE blocked or ignoring during an ex

Re: tee logs no output if stdout is closed

Bruno Haible wrote: > Paolo Bonzini wrote: >>> http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html >> Doesn't the comment in patch 2 > > To make it clear: > - Patch 1 only - applies if close_stdout were modified to ignore EPIPE > always (which Jim has rejected). > - Pat

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: > >> Imagine a scenario in which the pipe reader is expected always to >> be reading, and so the pipe writer can expect that any write failure with >> errno==EPIPE indicates the reader has terminated unexpectedly.

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > Imagine a scenario in which the pipe reader is expected always to > be reading, and so the pipe writer can expect that any write failure with > errno==EPIPE indicates the reader has terminated unexpectedly. >>> >>> The above was assuming that SIGPIPE is being igno

Re: tee logs no output if stdout is closed

Paolo Bonzini wrote: > > http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html > > Doesn't the comment in patch 2 To make it clear: - Patch 1 only - applies if close_stdout were modified to ignore EPIPE always (which Jim has rejected). - Patch 1 + 2 combined - applies if

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> Paolo Bonzini <[EMAIL PROTECTED]> wrote: >>> Jim, >>> Imagine a scenario in which the pipe reader is expected always to be reading, and so the pipe writer can expect that any write failure with errno==EPIPE indicates

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > Paolo Bonzini <[EMAIL PROTECTED]> wrote: >> Jim, >> >>> Imagine a scenario in which the pipe reader is expected always to >>> be reading, and so the pipe writer can expect that any write failure with >>> errno==EPIPE indicates the reader has terminated unexpectedly. >> If the

Re: tee logs no output if stdout is closed

Paolo Bonzini <[EMAIL PROTECTED]> wrote: > Jim, > >> Imagine a scenario in which the pipe reader is expected always to >> be reading, and so the pipe writer can expect that any write failure with >> errno==EPIPE indicates the reader has terminated unexpectedly. > > If the writer should terminate fi

Re: tee logs no output if stdout is closed

Bruno Haible wrote: > Paolo Bonzini wrote: >> Is it possible to implement the "tee >> --ignore-sigpipe" as you did (delaying SIGPIPE until the last input >> closes, which I also think is the right thing to do) while having >> close-stream ignore EPIPE? > > Yes it is. The complete patch was posted

Re: tee logs no output if stdout is closed

Jim, > Imagine a scenario in which the pipe reader is expected always to > be reading, and so the pipe writer can expect that any write failure with > errno==EPIPE indicates the reader has terminated unexpectedly. If the writer should terminate first, the reader can still detect the failure using

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> > EPIPE is part of the normal shutdown >> > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE. >> >> First, you're assuming that the pipe writer chooses to >> block or ignore SIGPIPE > > Yes, EPIPE only occurs

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > > EPIPE is part of the normal shutdown > > protocol of pipes, when the pipe writer chooses to block or ignore SIGPIPE. > > First, you're assuming that the pipe writer chooses to > block or ignore SIGPIPE Yes, EPIPE only occurs if SIGPIPE is blocked or ignored. > which is no

Re: tee logs no output if stdout is closed

Paolo Bonzini wrote: > Is it possible to implement the "tee > --ignore-sigpipe" as you did (delaying SIGPIPE until the last input > closes, which I also think is the right thing to do) while having > close-stream ignore EPIPE? Yes it is. The complete patch was posted here: http://lists.gnu.org/

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> >* lib/close-stream.c (close_stream): Ignore error EPIPE from fclose. >> > >> I know this condition arises only when ignoring or handling SIGPIPE, >> (which should be rather unusual) but even so, I really dislike the idea >> of ig

Re: tee logs no output if stdout is closed

> I cannot change 'close-stream', since you own that module. But for > 'fwriteerror', > which I use in GNU gettext - and where I don't want to have spurious, timing- > dependent error messages - I'm applying this: I tend to agree with you on EPIPE, but OTOH this is as bad as it can be. Can't we

Re: tee logs no output if stdout is closed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 9/26/2008 8:10 AM: >> I know this condition arises only when ignoring or handling SIGPIPE, >> (which should be rather unusual) but even so, I really dislike the idea >> of ignoring a write error. Even if the write error wo

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > > * lib/close-stream.c (close_stream): Ignore error EPIPE from fclose. > > > I know this condition arises only when ignoring or handling SIGPIPE, > (which should be rather unusual) but even so, I really dislike the idea > of ignoring a write error. Even if the write error

Re: tee logs no output if stdout is closed

Jim Meyering wrote: > If there is an EPIPE error, IMHO, close_stream must diagnose it. Well, then here is an amended patch (just for coreutils: 0001 and 0002, with a single ChangeLog entry) for the 'tee' program. The idea behind the patch is as follows: SIGPIPE is an optimization through which t

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > 2008-08-31 Bruno Haible <[EMAIL PROTECTED]> > > * lib/close-stream.c (close_stream): Ignore error EPIPE from fclose. > > --- lib/close-stream.c.orig 2008-08-31 17:18:56.0 +0200 > +++ lib/close-stream.c2008-08-31 17:14:12.0

Re: tee logs no output if stdout is closed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 8/31/2008 9:39 AM: > Right. close_stdout and more generally close_stream should be changed to > handle an EPIPE failure. An EPIPE errno value means that the kernel is telling > the program "This pipe/socket has no readers a

Re: tee logs no output if stdout is closed

Hi Jim, On 2008-07-01 you replied to a proposed new 'tee' option that makes it ignore SIGPIPE in : > Thanks for the patch, but I'm reluctant to use it > in part because it covers only the write syscalls deriving > from tee's e