7 ms·

Genuinely curious, why do you see this as a good change?

by lexicality 8y ago

saagarjha 8y ago
There are programs that violate POSIX and are picky about it.
- lexicality 8y ago
  Which ones?
- dfox 8y ago
  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.
  - saagarjha 8y ago
    > POSIX definition of what is text file actually requires the file to actually end with \n, so such programs are technically correct. No, they’re not correct, since they make files without the newline.
l24ztj 8y ago
Because if I type "hello" in a document, I expect the editor to save "hello", not "hello\n".
- lexicality 8y ago
  Where did you get that expectation? Every editor I've used up until Visual Studio Code did that by default. (I was actually very surprised when vscode _didn't_ do this!)
  - nikeee 8y ago
    I think it's uncommon in the Windows world.
  - l24ztj 8y ago
    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.
  - Sniffnoy 8y ago
    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".)
    - lexicality 8y ago
      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.
      - Sniffnoy 8y ago
        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.
- paavoova 8y ago
  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.
- badsectoracula 8y ago
  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.

Genuinely curious, why do you see this as a good change?

saagarjha 8y ago

There are programs that violate POSIX and are picky about it.

lexicality 8y ago
Which ones?
dfox 8y ago
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.
- saagarjha 8y ago
  > POSIX definition of what is text file actually requires the file to actually end with \n, so such programs are technically correct. No, they’re not correct, since they make files without the newline.

l24ztj 8y ago

Because if I type "hello" in a document, I expect the editor to save "hello", not "hello\n".

lexicality 8y ago
Where did you get that expectation? Every editor I've used up until Visual Studio Code did that by default. (I was actually very surprised when vscode _didn't_ do this!)
- nikeee 8y ago
  I think it's uncommon in the Windows world.
- l24ztj 8y ago
  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.
- Sniffnoy 8y ago
  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".)
  - lexicality 8y ago
    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.
    - Sniffnoy 8y ago
      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.
paavoova 8y ago
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.
badsectoracula 8y ago
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.