On Mon, 22 Apr 2024, 09:17 Carl Edquist, <edqu...@cs.wisc.edu> wrote:
> When I say "token" I just mean a record with whatever delimiter you're > referring to using. Ok that makes sense. Assuming the reading stops after consuming the first delimiter (which is > necessary for the 'read' builtin), then you end up with one system call per > line or record or token or whatever you want to call it. > That's what I was initially thinking of, but now I wonder whether the new kernel call should also accept a record count. […] I was saying the shell is crippled when limited to builtins; eg, a > read/printf loop compared to simply running cat. > I would hope that mapfile/readarray could do better, since it's not obligated to leave anything in the input stream. But yeah currently a pipe with a series of records and multiple > cooperating/competing readers perhaps only works if the records have a > fixed size. A new readd[elim] system call like you're talking about would > allow safely reading a single variable-length record at a time. > There are other options, such as length-prefixed records, or tagged (typed) records, but of course those aren't POSIX text files. > This starts to make me wonder whether mediated stdin could be more efficient? -Martin
