Re: RFC: yes as a filter

[Pádraig Brady]

On 17/02/16 22:42, Eric Blake wrote:
> I found myself wanting to reproduce a line of input multiple times, so
> my first thought was:
> 
> echo line | yes --some-option | consumer
> 
> to make yes read the first line of stdin and replay that, but we don't
> have such an option - the text to be replayed has to be passed on the
> command line. I ended up doing:
> 
> yes "$(echo line)" | consumer

Right that's a bit awkward and also limits the length of the line
to that supported by the system (128KiB on Linux).

> but wonder if it is worth adding such an option (maybe spelled
> --from-file, where '--from-file=-' reads from stdin).

This seems like the most general solution.
Whether it's warranted is the question.
I'm 50:50

> Using xargs for
> the task is not ideal, unless we have a way to make xargs shut up about
> EPIPE:
> 
> # echo line | xargs yes | head -n5
> line
> line
> line
> line
> line
> xargs: yes: terminated by signal 13

IMHO xargs should handle SIGPIPE differently:
http://www.pixelbeat.org/programming/sigpipe_handling.html
http://lists.gnu.org/archive/html/bug-findutils/2013-04/msg00026.html

Anyway one still has the size limit with an xargs solution.

> I guess this request also interacts with the recent question on whether
> 'yes' falls into the category of commands that should gain support to
> output data with NUL separators rather than newlines.

I was on the fence as to whether this was required,
but it would be more general to support -z, --zero
to delimit each _output_ item with NUL.

cheers,
Pádraig.