svn commit: r341803 - head/libexec/rc

[Devin Teske]

> On Dec 11, 2018, at 1:54 PM, Conrad Meyer <cem at FreeBSD.org> wrote:
> 
> On Tue, Dec 11, 2018 at 12:35 PM Devin Teske <dteske at freebsd.org> wrote:
>>> On Dec 11, 2018, at 11:57 AM, Conrad Meyer <cem at freebsd.org> wrote:
>>> Is there any interest in a tee(2)-like syscall?
>>> 
>> 
>> Linux has vmsplice(2). I know jmg@ also expressed interest in having a
>> vmsplice in FreeBSD.
> 
> Sure; they're related.  See also splice(2).  But tee(2) is probably
> the one that would be most useful here.
> 
>> As for sh not being able to read more than a single byte at a time because
>> it could be reading from a pipe, what if it read into a buffer and returned
>> a line from the buffer. A subsequent read would return more data from the
>> buffer, ad nauseam until the buffer runs out -- in which case another chunk
>> is read to augment the data.
>> 
>> This buffer could be expunged when stdin collapses (e.g., when the sub-
>> shell completes.
> 
> Yeah, this is basically what "buffered input" means.  An example of
> the problem with the naive solution is the scenario Warner pasted a
> few emails ago.  Take:
> 
>    foo | (read bar; baz)
> 
> (Where 'baz' is not a built-in.)  To implement this correctly with
> buffered 'read,' you have to somehow flush any input in the buffer
> beyond the end of the first line to the pipe that will be baz's stdin,
> as well as with the remaining contents of the pipe from foo (which
> may be indefinite).  That is what I suggested above as (A).
> 
> One big caveat is that you basically have to spawn a thread or process
> to keep feeding the input from the first pipe to the magical implicit
> pipe.  This overhead can be avoided readily in most scenarios if only
> the 'read' command is buffered.  Also, the described (read bar; baz)
> sub-program is a fairly odd construction, and the feeding isn't needed
> if no non-builtin programs after 'read' will access stdin.
> 
> If it helps paint a more concrete picture, imagine 'foo' as 'yes' and
> 'baz' as 'pv > /dev/null' or something (i.e., indefinite data source,
> indefinite data sink).

Thanks, this definitely illustrates the trouble.

In that case, would it be appropriate to say that:

	blah | while read x; do ...; done

Is always more efficiently written as:

	IFS=$'\n'
	for x in $( blah ); do ...; done

?
-- 
Devin