GNU bug report logs - #14246
tee can't continue when receiving SIGPIPE + adding a text mode option

Previous Next

Package: coreutils;

Reported by: Camion SPAM <camion_spam-gnubugs <at> yahoo.fr>

Date: Tue, 23 Apr 2013 13:03:01 UTC

Severity: normal

Tags: fixed

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 14246 <at> debbugs.gnu.org (full text, mbox):

From: Camion SPAM <camion_spam-gnubugs <at> yahoo.fr>
To: Pádraig Brady <P <at> draigBrady.com>,
	Eric Blake <eblake <at> redhat.com>
Cc: "14246 <at> debbugs.gnu.org" <14246 <at> debbugs.gnu.org>
Subject: Re: bug#14246: tee can't continue when receiving SIGPIPE + adding a
	text mode option
Date: Tue, 23 Apr 2013 20:45:46 +0100 (BST)
[Message part 1 (text/plain, inline)]
Eric Blake wrote : 

> Can't you already get this behavior by wrapping the tee 
> call inside stdbuf, which is already part of coreutils?
stdbuf is not usable to set stdin in line mode, and by the way tee is not buffered.

Eric Blake wrote : 

> Questions about how tee should behave on SIGPIPE have been raised in the
> past; we need consensus from the Austin Group to see what POSIX requires
> to know whether we can change the behavior by default or whether it
> requires a command-line option to tee.

IMO, the only reason for not catching SIGPIPE, is if one wishes processing_2 to be 
able to stop processing_1 by stopping the reading. It seems a bit awkwards to me, 
but why not. I'm not one who has the right to criticise other people strange 
scripting methods ;-D

Pádraig Brady wrote : 
> The more general tee --write-error={[cont],ignore,exit}
> should handle this http://bugs.gnu.org/11540
> It's nearly at the top of my TODO list.
It's not the same. Catching SIGPIPE is not about continuing on error, 
but about only stopping the output with the error, and not the others 
(when you have more than one output.) 
Both would probably complementary.

Pádraig Brady wrote : 
> tee works in non buffered mode by default
> so I need to consider the implications of  "text mode".

The patch I suggested is also working in non buffered mode
I called it text mode, only because it stops reading at every '\n'
Since it is mostly useful when you get input from a pipe and 
want output to appear line by line in screen, performance 
should not be too much of a problem.

Best regards
[Message part 2 (text/html, inline)]

This bug report was last modified 6 years and 219 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.