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