svn commit: r341803 - head/libexec/rc

[Conrad Meyer]

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).

Best,
Conrad