Missing newline check

[Boudhayan Gupta]

Hi Michael,

In Unix, text files are defined as a file containing *lines* of text [1].
Necessarily, this means that a character is required to signify the end of
line, which just happens to be the '\n' character.

Practically, this means certain Unix utilities, (although the GNU ones are
smart about this) will not count your last line, since it doesn't end with
a newline. GNU utilities try to sanitise your input by adding newlines
anyway (so the output of `printf "b\na" | sort | wc -c` is different from
the output of `printf "b\na" | wc -c`), and then there are countless
scripts out in the wild that, depending on how they're written, will try to
match a line using the newline character at the end.

In short, if it doesn't end with a newline character, by definition it's
not a line, and standards-compliant scripts and utilities are free to
ignore it.

Also in my private opinion, "modern" tools which don't get tripped up by
this are just contributing to sloppiness by developers, and also the lack
of awareness as to why you need a newline, and then you have devs who're
scratching their heads wondering why their stuff doesn't work when they're
forced to use one old tool that doesn't cover up for this sloppiness... so
the fact that Krazy is complaining loudly about this is a *very good* thing.

Thanks,
Boudhayan

[1]:
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_392

On Mon, 10 Dec 2018 at 09:56, Michael Reeves <reeves.87 at gmail.com> wrote:

> Why is krazy still checking for newlines at the end of files? Modern tools
> don't seem to get tripped up by this.
>
> http://ebn.kde.org/krazy/reports/kdereview/kdiff3/src/index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20181210/a95e5798/attachment.htm>