On Sat, Mar 12, 2016 at 12:08:10PM +0000, David Laight wrote: > On Mon, Mar 07, 2016 at 04:09:06PM +0700, Robert Elz wrote: > > > > Then I ktrace'd it, and of course, the "read" builtin command is reading > > one character at a time. If you think about it just a litte, you will > > see that it must work that way (it is only permitted to take one line of > > data from stdin, whatever follows the \n must be still available there for > > the next command, whatever it is.) > > It could do better if the input was seekable, but the shell is much > more likely to be reading from a pipe.
I'm not sure. A lot of shell processing also happens on real files. I asked Steve Bourne about this case today and he was a bit surprised that it hasn't been fixed yet :) > Clearly pipes could have had a 'line mode' - but they don't. TTYs do, don't they? > An interesting option would be getting recv(..., MSG_PEEK) > to work on pipes! > Actually since read() is just recv(fd, buf, len, 0) the entire > kernel could be converted to to support recv() instead of read(). > That would allow a MSG_LINE flag to be implemented that terminated > on a '\n' character. Actually I was wondering if there aren't more use cases for a "read until you find the following sequence" system call or just something specifiying a (simple) regular expression. Even a BPF program would be an interesting option. Joerg
