Both POSIX and SUS (Single UNIX Specification) define a line as

A sequence of zero or more non-<newline> characters plus a terminating <newline> character.

Many distributions are more oriented towards LSB than POSIX. LSB includes a lot of POSIX/SUS standards but not all exactly.

Must lines also be terminated with a NEWLINE character in regards to LSB v4.1 ?

2 Answers 2


From the chapter on "Scope":

The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB.


The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.

For the things that the LSB does not define, such as most things relating to the behavior of standard utilities (except for certain extensions) and definitions of basic terms, it refers to the POSIX standard (which is a normative reference for the LSB, i.e. the LSB builds on top of POSIX).

The POSIX standard tells us that a line is

A sequence of zero or more non-<newline> characters plus a terminating <newline> character.

This means that a line of text must be terminated by a newline character, even on a system conforming to the LSB 4.1 standard.


You seem to misunderstand the consequences of this POSIX requirement.

Something that does not end in a newline just is no line.

This results e.g. in wc reporting 0 lines if a file contains no newline at all, which is true even on Linux.

Your added new question looks a bit different from the first question, as it asks for specific use cases and resulting problems.

First, a longer file that does end in a newline causes other problems that are not related to Linux. If a C include-file does not end in a newline, this may cause a C-source that #includes this file to fail if the text on next line in the C-source only works as expected in case that it is on the beginning of a line.

Furthermore, there are some programs that ignore the last line in a file if it is not terminated by a newline.

Software like SCCSv4 and SCCSv5 classifies a file to be "binary" if it contains a nul byte or does not end in a newline. This results in sub-optimal handling of deltas.

Finally, LSB is a binary standard internally to Linux, but files are copied between different platforms and even if LSB would differ from POSIX in this area, this did not change the relevance of the rules from POSIX.

Maybe it helps to know that in former times, there was no editor on UNIX that could create a file that does not end in a newline. The first editor that could create such files was the Gosling EMACS from 1979 followed by VED from UNOS (the first UNIX clone) in 1980.

So it seems to be good practice to tell your users to avoid such files...

  • Yes, you are not wrong. Everything else would be an incomplete line. But as little background of my question: I was special interested in the last line of a text file. One of my colleges refused to setup his editor "correctly" so that files end with <newline> character. He tried to argue with: "Linux is not POSIX compliant , it's LSB-compliant." Jun 14, 2020 at 16:22
  • OK, I enhanced my answer to explain the consequences of your new question.
    – schily
    Jun 14, 2020 at 17:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .