On Mon 06 Jul 2026 at 18:27:01 +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. K&R Second Edition (mine is "Based on Draft-Proposed ANSI C") says on page 15, para 1.5 "Character Input and Output": A /text stream/ is a sequence of characters divided into lines; each line consists of zero or more characters followed by a newline character. but then also, next: It is the responsibility of the library to make each input or output stream conform to this model; the C programmer using the library need not worry about how lines are represented outside the program. So in theory the library has the option to convert trailing garbage into a line by appending a newline. Or it can declare that a file not ending in a newline does not represent a text stream and refuse to open it. But the program has to ignore any garbage that doesn't end with a newline, too. -Olaf. -- ___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl> \X/ There is no AI. There is just someone else's work. --I. Rose
Attachment:
signature.asc
Description: PGP signature