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

Re: tee logs no output if stdout is closed

Phillip Susi <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >> It would match the behaviour as defined by ASYNCHRONOUS EVENTS in 1.11 >> Utility Description Defaults. > > Could you quote that section or give me a url to somewhere I can see it > myself? I have no idea what it says nor where t

Re: tee logs no output if stdout is closed

Andreas Schwab wrote: It would match the behaviour as defined by ASYNCHRONOUS EVENTS in 1.11 Utility Description Defaults. Could you quote that section or give me a url to somewhere I can see it myself? I have no idea what it says nor where to look it up. Also what about the issue where tee

Re: tee logs no output if stdout is closed

Phillip Susi <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >>> It seems to me that tee should have a SIGPIPE handler which closes the >>> broken fd and stops trying to write to it, and if ALL outputs have been >>> closed, exit. >> >> That would not be compatible with POSIX. > > In what way?

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> wrote: > Andreas Schwab wrote: >> > How about adding an option '-p' to 'tee', that causes it to ignore SIGPIPE >> > while writing to stdout? >> >> Just add a trap '' SIGPIPE before starting tee. > > Thanks, this does half of the trick: Each 'tee' invocation then wri

Re: tee logs no output if stdout is closed

Andreas Schwab wrote: It seems to me that tee should have a SIGPIPE handler which closes the broken fd and stops trying to write to it, and if ALL outputs have been closed, exit. That would not be compatible with POSIX. In what way? Also, won't ignoring SIGPIPE cause problems later when tee

Re: tee logs no output if stdout is closed

Andreas Schwab wrote: > > How about adding an option '-p' to 'tee', that causes it to ignore SIGPIPE > > while writing to stdout? > > Just add a trap '' SIGPIPE before starting tee. Thanks, this does half of the trick: Each 'tee' invocation then writes the complete stdin contents to the log file.

Re: tee logs no output if stdout is closed

Phillip Susi <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote: >> Bruno Haible <[EMAIL PROTECTED]> writes: >> >>> How about adding an option '-p' to 'tee', that causes it to ignore SIGPIPE >>> while writing to stdout? >> >> Just add a trap '' SIGPIPE before starting tee. > > Wouldn't that only t

Re: tee logs no output if stdout is closed

Andreas Schwab wrote: Bruno Haible <[EMAIL PROTECTED]> writes: How about adding an option '-p' to 'tee', that causes it to ignore SIGPIPE while writing to stdout? Just add a trap '' SIGPIPE before starting tee. Wouldn't that only trap SIGPIPE sent to the shell, not tee? Aren't all signal

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> writes: > How about adding an option '-p' to 'tee', that causes it to ignore SIGPIPE > while writing to stdout? Just add a trap '' SIGPIPE before starting tee. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 9

Re: tee logs no output if stdout is closed

Andreas Schwab wrote: > It also says: > > ASYNCHRONOUS EVENTS > Default ... That indeed appears to imply that when writing a pipe with no readers, the 'tee' process should be killed. This is appropriate for utilities which produce no side effects, i.e. whose _only_ purpose is to produce out

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> writes: > If 'tee' was to write to the log file(s) first and then only to stdout, and > if the input is small (does not need buffering), then its stdin input would > show > up in the output, and this would also be POSIX compliant. Just put a 'cat >/dev/null' in t

Re: tee logs no output if stdout is closed

Andreas Schwab wrote: > > $ rm -f empty; touch empty; rm -f output output2; \ > > for a in 0 1 2 3 4 5 6 7 8 9 ; do \ > > for b in 0 1 2 3 4 5 6 7 8 9 ; do \ > > echo g$a$b | tee -a output; \ > > echo h$a$b >> output2; \ > > done; \ > > sleep 2; \ > > done \ > > | { sl

Re: tee logs no output if stdout is closed

Bruno Haible <[EMAIL PROTECTED]> writes: > tee appears to drop its input (i.e. it does not write it into the specified > log file) if stdout is closed. > > I didn't expect this behaviour, and POSIX >http://www.opengroup.org/susv3/utilities/tee.html > does not mandate this behaviour either. Rat