Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

LF makes the most sense, but they're all fine for text files. The issue is that CSV isn't text.

Last time I had to handle CSV files in bash, I converted them internally to RS and FS.



Line feed resetting position really makes no sense. It should just continue text from where the cursor was but on next line. Like staircase. You need CR to go back to start.


It makes perfect sense when you consider text files. When line ends, next line obviously starts from column zero.

CR is the only wrong choice. There's never a reason to go to start of line without erasing the line or moving to next line in a file. And even user interfaces will have smarter ways to do that. It's a completely useless concept outside of typewriters.

Well, CRLF (or worse, LFCR) is also obviously a wrong choice because it's pointless to demand two characters and create problems when one of them is missing when one totally unambiguous character will do.


Yes, if you're talking to a terminal. But an in-disk file doesn't have a carriage to return.


Modern computer text output devices don’t have a “carriage” or a “feed” mechanism. I’d argue both CR and LF are legacy, anachronistic characters whose purpose was too device specific to make sense as a text encoding.


Sure, there's a text encoding part and an equipment control part that puts the CII in ASCII.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: