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 diagnostic in this

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 called

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: /* Tell

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 http://lists.gnu.org/archive/html/bug-coreutils/2008-09/msg00024.html From a4434d71a1a3ec7a6aee6de4a81da36301b12a28 Mon Sep 17 00:00:00 2001 From: Bruno Haible [EMAIL PROTECTED] Date: Mon, 6 Oct 2008 02:58:58

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 that having SIGPIPE

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/EPIPE

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

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 ignoring a write

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:

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 not

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 if SIGPIPE is

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 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 here:

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 first, the

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 writer should

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 the reader has

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: 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

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). - Patch 1 + 2

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 execve() or

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 global

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: 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_stdout

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 another.

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 would

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 would

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 +0200 @@

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

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 any

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 http://lists.gnu.org/archive/html/bug-coreutils/2008-07/msg5.html: Thanks for the patch, but I'm reluctant to use it in part because it covers only the write syscalls deriving from tee's

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 to look it

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

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

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 writes the

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? It would match

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. Rather, it

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 \ | { sleep 1; join

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 the

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 output

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,

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

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 trap SIGPIPE sent to

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. But

tee logs no output if stdout is closed

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. Rather, it says: If any file operands are specified,