Date: Tue, 11 Dec 2018 14:42:02 -0800 From: Devin Teske <dteske@FreeBSD.org> To: cem@freebsd.org Cc: Devin Teske <dteske@FreeBSD.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r341803 - head/libexec/rc Message-ID: <917251B0-00E0-47E2-B6FB-568EDB9ED781@FreeBSD.org> In-Reply-To: <CAG6CVpXVNYyQmdZcADBE_CJB1toKPdnHZEfY54Do-OcYeDAzJg@mail.gmail.com> References: <201812110138.wBB1cp1p006660@repo.freebsd.org> <2a76b295-b2da-3015-c201-dbe0ec63ca5a@FreeBSD.org> <98481565-CDD7-4301-B86B-072D5B984AF7@FreeBSD.org> <dafbcc18-146f-2e4f-e1e9-346d7c05b096@FreeBSD.org> <CANCZdfqtyvxCBwdwDQ4Raeven2LmaPd3C-c---pVFhHDWBKfxA@mail.gmail.com> <CAG6CVpVtWL448-pxW9EK7SEe7Cfk1mkCvPNmtE=YuFWM3Bn0tA@mail.gmail.com> <C3D7104B-2A6F-4BF0-865C-B941651EDD1A@FreeBSD.org> <CAG6CVpXVNYyQmdZcADBE_CJB1toKPdnHZEfY54Do-OcYeDAzJg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Dec 11, 2018, at 1:54 PM, Conrad Meyer <cem@FreeBSD.org> wrote: >=20 > On Tue, Dec 11, 2018 at 12:35 PM Devin Teske <dteske@freebsd.org> = wrote: >>> On Dec 11, 2018, at 11:57 AM, Conrad Meyer <cem@freebsd.org> wrote: >>> Is there any interest in a tee(2)-like syscall? >>>=20 >>=20 >> Linux has vmsplice(2). I know jmg@ also expressed interest in having = a >> vmsplice in FreeBSD. >=20 > Sure; they're related. See also splice(2). But tee(2) is probably > the one that would be most useful here. >=20 >> 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. >>=20 >> This buffer could be expunged when stdin collapses (e.g., when the = sub- >> shell completes. >=20 > 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: >=20 > foo | (read bar; baz) >=20 > (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). >=20 > 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. >=20 > 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=3D$'\n' for x in $( blah ); do ...; done ? --=20 Devin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?917251B0-00E0-47E2-B6FB-568EDB9ED781>