[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: yes as a filter

From: Pádraig Brady
Subject: Re: RFC: yes as a filter
Date: Wed, 17 Feb 2016 23:12:51 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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
> # echo line | xargs yes | head -n5
> line
> line
> line
> line
> line
> xargs: yes: terminated by signal 13

IMHO xargs should handle SIGPIPE differently:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]