POSIX definition of what is text file actually requires the file to end with \n, so such programs are technically correct.
The reason why this is (and also why the lines should not be longer than LINE_MAX or contain \0) is that when you simply call fgets() in a loop with LINE_MAX sized buffer, all of these things cause perfectly logical, but wrong/surprising behavior. This is the reason why almost any modern small unix tool contains something called myfgets(), getline() or whatever which wraps fgets() in loop with realloc() and correctly distinguishes eof from other errors.
I mean, it ought to be possible to use a text editor to specify exactly what I want in a text file. If a newline is silently added at the end, then, well, that isn't happening.
Edit: Which is to say, I don't think l24ztj is using "expect" in the sense of "anticipate" but rather, y'know, the other sense. (Using Wiktionary's definitions: "To consider obligatory or required" or "To consider reasonably due".)
It should be possible, sure, just like it should be possible to forgo utf-8 and save your file with the iso-8859-1 encoding. But it's the less useful case. Many (most) programs do not care whether there is a final newline or not, but among those that do care, missing endlines will run you into more problems than the opposite (e.g.: Git, GCC, wc and cron will either complain or not work as expected).
What do you mean by "exactly" though? What is the "exact" value of "e"? 0x65? How about "é"?
You expect your editor to take what you've written and provide a valid text file with that information in it, which can then be read by something else. Applying the correct text encoding (UTF-8?) and adding a 0x0A as the last byte are part of making it valid.
If you want to specify the exact bytes on disk, you should use a hex/bin editor.
The correct text encoding is the one I specify. UTF-8 is a decent default. Where did that bit about 0x0A come from? That's just an extra byte. There's no text encoding that says "to decode this you should first remove the 0x0A at the end, which is not part of the text".
I should only need a hex editor if I want to make a file that can't be decoded as text under a known encoding, and no encoding I know (and certainly none that I use) has the encoding/decoding rule I mentioned above. I certainly shouldn't need one just to make a validly-encoded UTF-8 file that happens to end in a character other than a newline.
Basically, either it's part of the encoding or it's part of the text, and if it's part of the text, I ought to be able to control it. And it isn't part of the encoding.
> I mean, it ought to be possible to use a text editor to specify exactly what I want in a text file.
I agree. But for me a text file that does not end in newline is badly formed. It is not a text file, it is a binary file that happens to contain some printable characters.
I have the opposite experience: notepad, notepad++, vscode, kwrite/kate, sublime, gedit, and many more I've used... none of them had this unwanted behaviour.
Yes, but now if you do $ wc -l hello.txt, it will say 0. If a program is reading line by line, it won't get a full line if the last line is not terminated - this can lead to unwanted behavior, such as when you're matching end of line with regex.
This is a Unix thing, on Unix lines in text files are terminated and the terminator is supposed to always be there to mark the end of the line, as opposed to Windows where they are separated and a separator at the end of the file means that the text has an empty line at the end.
This is also why tools that have a Unix heritage tend to complain if there is no terminator/separator at the end of the file (even in Windows), like most C compilers.
The old behaviour is the sane default, at least for editing text files. POSIX defines a text file as a file consisting of a number of lines, each terminated by an LF character.
Especially a 2019 user, 20+ years removed from the systems, decisions, and rationales, behind POSIX.
Just try to get someone (even a seasoned Linux user) to use a POSIX-only userland (as opposed to GNU), as see how fast they'll be pulling their hair out...
I would say it's not just a POSIX demand. Most unix tools are POSIX-complaint, and the user should expect just it and nothing more. Non-proper text files without LF at the end may not be processed properly, so to be assured that everything works fine that LF is mandatory.
Such an insane default. Currently programming a bittorrent client and was edited files to test some functionality. Was confused for a long time until I realized nano was turning my "echo 'this is a test' > test" into "echo 'this is a test\n' > test"