On Mon, Jul 06, 2026 at 06:27:01PM +0200, Edgar Fuß wrote: > I stumbled over the fact that sh's read returned 1 on the final part > (call it a line or not) of a file when it didn't end in a newline. > > Digging through SUS revealed (in the informative part of read): > > Although the standard input is required to be a text file, and > therefore will always end with a <newline> (unless it is an empty file) > > as well as other passages that suggested that a "text file" consists of > "lines" and a "line" is a sequence of non-newline characters plus a newline, > but I couldn't find a definition explicitly stating that.
Poor looking on your part (line numbers from POSIX.1-2024):
1799 3.185 Line
1800 A sequence of zero or more non-<newline> characters plus a terminating
<newline> character.
2661 3.387 Text File
2662 A file that contains characters organized into zero or more lines. The
lines do not contain NUL
2663 characters and none can exceed {LINE_MAX} bytes in length, including the
<newline>
2664 character. Although POSIX.1-2024 does not distinguish between text files
and binary files (see
2665 the ISO C standard), many utilities only produce predictable or meaningful
output when
2666 operating on text files. The standard utilities that have such
restrictions always specify ``text
2667 files’’ in their STDIN or INPUT FILES sections.
And the "final part" is an
1740 3.172 Incomplete Line
1741 A sequence of one or more non-<newline> characters at the end of the file.
(only ex and sort use this concept at all).
If we're married to the SUS, SUSv1 (Issue 4 Version 2) says much the same thing
(System Interface Definitions Issue 4, Version 2; pp. 19, 30, 18):
line
A sequence of zero or more non-newline characters plus a terminating newline
character.
text file
A file that contains characters organised into one or more lines. The lines
must not contain NUL
characters and none can exceed {LINE_MAX} bytes in length, including the
newline character.
Although the XSI does not distinguish between text files and binary files (see
the ISO C
standard), many utilities only produce predictable or meaningful output when
operating on text
files. The standard utilities that have such restrictions always specify text
files in their STDIN or
INPUT FILES sections.
The term text file does not prevent the inclusion of control or other
non-printable characters
(other than NUL). Therefore, standard utilities that list text files as inputs
or outputs are either
able to process the special characters gracefully or they explicitly describe
their limitations
within their individual sections. The only difference between text and binary
files is that text
files have lines of less than {LINE_MAX} bytes, with no NUL characters, each
terminated by a
newline character. The definition allows a file with a single newline
character, but not a totally
empty file, to be called a text file. If a file ends with an incomplete line it
is not strictly a text file
by this definition. The newline character referred to in this document set is
not some generic line
separator, but a single character; files created on systems where they use
multiple characters for
ends of lines are not portable to all XSI-conformant systems without some
translation process.
incomplete line
A sequence of one or more non-newline characters at the end of the file.
(the second para in "text file" is moved to XRAT in POSIX.1-2024)
signature.asc
Description: PGP signature
