bug#14246: tee can't continue when receiving SIGPIPE + adding a text mode option

[Camion SPAM]

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