Re: sh(1) read: add LINE_MAX safeguard and "-n" option

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

    Date:        Wed, 25 Sep 2024 15:12:07 +0200
    From:        tlaronde%kergis.com@localhost
    Message-ID:  <ZvQMJ3R9acn4LXa2%kergis.com@localhost>

  | FWIW, you will find below a proposed solution:

Thanks, but there is no need, I will make it work eventually.

I like that you got rid of atoi() from the previous version, but
sh has a function number() which not only gets an int (just an int,
but that's enough for any rational use here) and does all the syntax
check, and error handling for it, which is what should be used.

  | If the delimiter is not specified, it is the default '\n', to the
  | input stream is supposed to be a POSIX text file. The maximum length
  | of a "line" is LINE_MAX.

That's not exactly what it is intended to be - LINE_MAX is the limit
applications are supposed to keep line under, as that's what applications
are required to support (as a minimum) - there's nothing that says that
the application can't support longer lines - even unlimited length ones
(within available memory if the whole line needs to be stored), and
not imposing unnecessary limits is generally a much better result.

  | When called like:
  | read myvar <myfile

I know you're trying to find a way to make that portable usage run
much faster (at least with our shell, we won't be improving any others)
but making changes like this to meet the specific needs of one application
isn't what we ought to be doing.   (I haven't really looked at the script
but my guess would be that there are other changes that could be made which
would improve performance more than what this one could do.)

  | If '-d' is used, even with '\n', linemax is reset to READ_UNLIMITED,

Why would there be a difference between '\n' as the default delimiter
and '\n' explicitly set?   You're requiring applications that might work
just fine right now to change to meet your new restriction - it should be
the other way around, applications that need the new feature (limited
length reads) should be changed to request it.

  | I have dropped trying to count (for '-n') only bytes effectively put
  | in the "record" for 2 reasons:

That was probably always the wrong approach, is read is supposed to
read a max of N bytes, it should read no more than that, whatever is
done with them afterwards.

But to be compatible with the other shells that have -n (in this fashion)
a read from a device should complete as soon as N bytes are available,
not wait for more to appear to allow the read to succeed - that means
that the terminal has to have canonical processing turned off, and that
means that we need to consider what happens when the ERASE (etc) chars
are entered.

Thanks for the effort, but please stop now.

kre