Re: sh read on files missing the final newline

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

    Date:        Thu, 9 Jul 2026 10:47:21 +0200
    From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <ak9gGRqF662zvWIY%trav.math.uni-bonn.de@localhost>

  | I seem to be confused about the relation of POSIX and SUS.
  | What I have is called sus4tc2 and the header says
  |
  | 	The Open Group Base Specifications Issue 7
  | 	IEEE Std 1003.1-2008, 2016 Edition
  |
  | and there's no read -d in that.

That's POSIX issue 7 (2016, so it includes TC2),   And you're right
the -d option was added in Issue 8 (2024), I just thought it was there
for longer than that.

In general when a reference is just made to SUS it tends to be interpreted
as the standard (such as it was) that existed before POSIX was invented.

  | As there's no way to tell whether a complete line had data in it or not, no?

If you get a 0 return from read, you know the delimiter existed, so
the variable values will tell you what was there.   With a 1 return,
the EOF might have come immediately after the previous delimiter, or
there might have been intervening data, if all of it was IFS characters,
all the vars will be ''.   You could read with IFS='' & -r (and just one
variable, more would be wasted), in which case that var gets whatever was
in the record (no changes at all) - since the exit status was 1, you know
no delimiter was found, then if the var=='' you know the record was empty
(the EOF was immediately after the previous delimiter).   If [ -n "${var}" ]
then you could reset IFS to what it would have been normally, and use
	set -- $var
(you'd also want set -f to avoid filename generation) to split the thing
into fields.  If you wanted read style splitting (the trailing everything
in one field/var) you could use

	read a b c <<!
	${var}
	!

to read each record into the vars - including the one (if it is determined
to exist) after the final delimiter.

  | Is that distinction between rc=1 and rc>1 standardised?

Yes.

  | What confuses me even more is that current's sh(1) manpage says
[...]
  | so that' doesn't distinguish between EOF and I/O error.

It doesn't, that's a bug, which I should fix, but not today (I/O errors
while doing read(1) are not very common!).   File a PR on it please.

kre