Re: abysmal check-portability speed

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 25 Sep 2024 22:12:32 +0200 (CEST)
    From:        Thorsten Glaser <tg%mirbsd.org@localhost>
    Message-ID:  <fb3a6882-a0cd-a22b-9f88-6c421fe60ab0%mirbsd.org@localhost>

  |     -n z   Instead of reading till end-of-line, read up to z bytes but
  | 	   return as soon as any bytes are read, e.g. from a slow ter‐
  | 	   minal device, or if EOF or a timeout occurs.
  |
  | What exactly is unclear with that?

read is defined to stop reading at the delimiter, "read up to z bytes"
should mean "bytes up to the delimiter but no more than z", the
"but return as soon as any bytes are read" looks to be just like
an extra limitation (which to me makes no sense at all, as if reading
from a terminal which is in raw mode it will return after the first
char is typed - what good is that?).

Your doc doesn't say that the delimiter is ignored.

And since you're apparently ignoring the delimiter, do you also
ignore the splitting, it appears (from experimentation) not, but
the doc doesn't say.

  | >If/when we add -n, it will certainly act like that, and not:
  | That’s positively harmful.

Nonsense.

  | Consider:
  |
  | 	$ (printf 'foo\nbar\n'; printf 'baz\n') | mksh -c '
  | 	>         read -n 128 foo
  | 	>         echo one: $foo
  | 	>         read -n 128 foo
  | 	>         echo two: $foo
  | 	> '
  | 	one: foo bar
  | 	two: baz

Yes, let's:

jacaranda$ (printf 'foo\nbar\n'; printf 'baz\n') | bash -c '
read -n 128 foo
echo one: $foo
read -n 128 foo
echo two: $foo
'
one: foo
two: bar

That's bash obviously, but when our implementation is done
it will work just the same.   And obviously if there had
been a third read, that would have read the third line.

ksh93 works the same way.

And incidentally, in my system:

jacaranda$ (printf 'foo bar\n'; printf 'baz\n') | mksh -c '
read -n 128 foo bar
echo one: foo=$foo bar=$bar
read -n 128 foo
echo two: $foo
'
one: foo=foo bar=bar baz
two:

I guess the printf's happen fast enough that both of them
produce output before mksh is ready to read it.

Whereas:

jacaranda$ (printf 'foo bar\n'; sleep 1; printf 'baz\n') | mksh -c '
read -n 128 foo bar
echo one: foo=$foo bar=$bar
read -n 128 foo
echo two: $foo
'

That kind of difference is absurd, and completely useless.
It is just a race condition waiting to happen.

  | The read builtin must retain correct position of the file
  | descriptor used at any time (the second “read -n 128 foo”

Yes, definitely, I agree.

  | So, I fear that the method you want to implement is impossible.

No, it isn't, the actual read reads 1 byte at a time, stopping
at the delimiter, or at the byte count, whichever comes first.
"read up to z bytes" doesn't mean "do one read of z bytes".

kre