5 ms·
>A newline character is no longer automatically added at end of buffer. yesssssssssss
by l24ztj 8y ago
>A newline character is no longer automatically added at end of buffer.
yesssssssssss
- emilfihlman 8y agoThis has been a configurable option since forever.
- tyingq 8y agoSane defaults still have value.
- OJFord 8y agoMany would say the old behaviour was the sane choice - apart from anything else it's consistent with vi(m) and git.
- tyingq 8y agoI suppose. Though you might expect a GNU editor to follow Emacs for this behavior.
- nemetroid 8y agoThe 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.
- coldtea 8y agosane is what the user expects, not what POSIX demands.
- lexicality 8y agoOne could reasonably expect that a user expects a POSIX system to behave according to the POSIX standards?
- williamdclt 8y agoNot really, most users (even tech people) don't know that it is a POSIX standard, or what's a POSIX standard, or what's POSIX really
- lexicality 8y agoAre you thinking about most people who use a computer or most people who use a CLI based editor that's presumably on a remote machine they just sshed into?
- coldtea 8y agoI'd say both sets. Hardly any of my colleagues knows what POSIX is (and surely not in any depth, even those that do), but they still SSH and use editors that include Vim all the time... I'd say in a company of 50+ SSHing people, around 5-6 know POSIX and its history, and usually the older ones (35+).
- unveres 8y agoI think it's better to expect more from a specialist than less. ;)
- coldtea 8y agoA sysadmin maybe. A user hardly. 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...
- unveres 8y agoI 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.
- marcosdumay 8y agoIf I would bother configuring an editor I would not be using nano.
- lexicality 8y agoGenuinely curious, why do you see this as a good change?
- saagarjha 8y agoThere are programs that violate POSIX and are picky about it.
- lexicality 8y agoWhich ones?
- dfox 8y agoPOSIX 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 agoBecause if I type "hello" in a document, I expect the editor to save "hello", not "hello\n".
- lexicality 8y agoWhere 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!)
- mruts 8y agoSuch 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"
- symlinkk 8y agoFunny you mention echo, which prints a newline by default as well.
- lexicality 8y agoPretty sure nano was changing your code to echo 'this is a test' > test\n and then echo was adding the newline because you didn't specify -n.
- pushpop 8y ago...and also echo 'this is a test\n' doesn't produce an additional new line because -e wasn't specified.
- nemetroid 8y agoRunning "echo 'this is a test' > test" produces a file with a newline at the end.