<div dir="auto">In unix context that probably makes sense for comparability. Especially for commandline tools. In any event I use vscode which can silently and this. Give that it must be there it makes sense to just have it happen on its own. I already do this with code formatting. Its nice not to have to constantly think about it while coding.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018, 3:11 AM David Faure <<a href="mailto:faure@kde.org">faure@kde.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"cat file1.cpp file2.cpp > file3.cpp" will be broken in the contexts in which <br>
you don't support that file1.cpp should end with a newline.<br>
<br>
IMHO text editors should (and most do) just ensure a newline is present at the <br>
end so that this all works without human intervention.<br>
<br>
David.<br>
<br>
On lundi 10 décembre 2018 13:47:46 CET Michael Reeves wrote:<br>
> Thanks for the reply in my view not treating endof file as newline is a<br>
> flaw in the standard itself. But that's not my call for a kde app. I will<br>
> not be supporting this outside kde context with regard to source files.<br>
> <br>
> On Mon, Dec 10, 2018, 6:30 AM Boudhayan Gupta <<a href="mailto:bgupta@kde.org" target="_blank" rel="noreferrer">bgupta@kde.org</a> wrote:<br>
> > Hi Michael,<br>
> > <br>
> > In Unix, text files are defined as a file containing *lines* of text [1].<br>
> > Necessarily, this means that a character is required to signify the end of<br>
> > line, which just happens to be the '\n' character.<br>
> > <br>
> > Practically, this means certain Unix utilities, (although the GNU ones are<br>
> > smart about this) will not count your last line, since it doesn't end with<br>
> > a newline. GNU utilities try to sanitise your input by adding newlines<br>
> > anyway (so the output of `printf "b\na" | sort | wc -c` is different from<br>
> > the output of `printf "b\na" | wc -c`), and then there are countless<br>
> > scripts out in the wild that, depending on how they're written, will try<br>
> > to match a line using the newline character at the end.<br>
> > <br>
> > In short, if it doesn't end with a newline character, by definition it's<br>
> > not a line, and standards-compliant scripts and utilities are free to<br>
> > ignore it.<br>
> > <br>
> > Also in my private opinion, "modern" tools which don't get tripped up by<br>
> > this are just contributing to sloppiness by developers, and also the lack<br>
> > of awareness as to why you need a newline, and then you have devs who're<br>
> > scratching their heads wondering why their stuff doesn't work when they're<br>
> > forced to use one old tool that doesn't cover up for this sloppiness... so<br>
> > the fact that Krazy is complaining loudly about this is a *very good*<br>
> > thing.<br>
> > <br>
> > Thanks,<br>
> > Boudhayan<br>
> > <br>
> > [1]:<br>
> > <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#ta" rel="noreferrer noreferrer" target="_blank">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#ta</a><br>
> > g_03_392> <br>
> > On Mon, 10 Dec 2018 at 09:56, Michael Reeves <<a href="mailto:reeves.87@gmail.com" target="_blank" rel="noreferrer">reeves.87@gmail.com</a>> wrote:<br>
> >> Why is krazy still checking for newlines at the end of files? Modern<br>
> >> tools don't seem to get tripped up by this.<br>
> >> <br>
> >> <a href="http://ebn.kde.org/krazy/reports/kdereview/kdiff3/src/index.html" rel="noreferrer noreferrer" target="_blank">http://ebn.kde.org/krazy/reports/kdereview/kdiff3/src/index.html</a><br>
<br>
<br>
-- <br>
David Faure, <a href="mailto:faure@kde.org" target="_blank" rel="noreferrer">faure@kde.org</a>, <a href="http://www.davidfaure.fr" rel="noreferrer noreferrer" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
<br>
<br>
</blockquote></div>