Re: sh read on files missing the final newline

[Edgar Fuß <ef%math.uni-bonn.de@localhost>]

This is getting interesting in ways I didn't expect (other than that I'm always 
learning something new about sh as soon as kre chimes in).

> The change to add different delimiters than \n is more recent than SUS
> (I think it appeared in Posix 7 (would be 2008 probably, but could perhaps
> be one of its updates, 2013, 2016, 2018?) but I haven't verified that).
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.

> Before then, all read records were terminated by \n, which made them be
> lines.
I didn't know about read -d.

> If, for example, IFS=: (and we leave the end delim as \n for simplicity)
> then
> 	::
> would generate foo='' bar='' baz='' regardless of whether that second
> ':' is followed by \n or by EOF.   So there simply is no reliable way
> to know for sure if an incomplete line had data on it or not.
As there's no way to tell whether a complete line had data in it or not, no?

> But if your data makes that kind of thing impossible
Or if I don't care about the file having a final NL or having been mangled 
by a LISP OS with built-in editing capabilities.

> in order to avoid doing another read after one has returned 1, and treating
> a status of >1 as always being fatal (that would happen if we had had
> 	readonly foo
> prior to this, or similar, could also happen on a read I/O error).
Is that distinction between rc=1 and rc>1 standardised?

What confuses me even more is that current's sh(1) manpage says

	The read built-in utility will indicate success (exit status 0)
	unless EOF, or a read error, is encountered on input, before
	encountering the delimiter, or having read max bytes.  In this
	case any data previously read will be assigned to the variables,
	as if the delimiter had been located at that point, and read will
	exit with status 1.  If there is a usage error (unknown option,
	etc) no variables will be altered, read will issue a diagnostic to
	standard error, and exit with a status greater than 1.

so that' doesn't distinguish between EOF and I/O error.

I think I can cope with my script going havoc in case I call read with 
illegal options or on RO variables.