lineSplitter ignores the the trailing newline?

Patrick Schluter Patrick.Schluter at
Sun Nov 10 12:29:12 UTC 2019

On Saturday, 9 November 2019 at 23:07:29 UTC, Jonathan Marler 
> On Saturday, 9 November 2019 at 23:04:11 UTC, Jonathan Marler 
> wrote:
>> On Saturday, 9 November 2019 at 19:28:52 UTC, Paul Backus 
>> wrote:
>>> On Saturday, 9 November 2019 at 19:00:31 UTC, Jonathan Marler 
>>> wrote:
>>>> [...]
>>> lineSplitter follows the Unix convention of treating newlines 
>>> as line *terminators* rather than line *separators* (as we 
>>> can see from the name of its template argument 
>>> "KeepTerminator"). Under this convention, a trailing newline 
>>> terminates the final line in a file, but does not start a new 
>>> one, so there is no need for an additional empty line.
>> Interesting, do you have any links and or references that 
>> establish that unix uses newlines as terminators rather than 
>> separators?
> Also, if unix is using it as a "terminator" instead of a 
> "separator", if you don't have a trailing newline at the end of 
> the file then the last line wouldn't be "terminated" properly, 
> so should you ignore the last line?  Should that be an error?
> If so, then it sounds like the correct solution for the "tolf" 
> tool is to always make sure the last line is terminated with a 
> newline character.  Does that sound correct?

It would be necessary also for most Unices that don't use glibc. 
In a lot of libc implementation (Solaris definitely has the bug) 
fgets() doesn't return correctly the last line if it has no line 
feed. glibc corrects this behaviour so that most Linux users 
don't know about this issue.

More information about the Digitalmars-d mailing list