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.
(I was actually very surprised when vscode _didn't_ do this!)