@MET said:
@LizardKing said:The line endings thing is more of a Windows WTF. In the Windows world, text files and binary files are distinct from each other - this is why FTP clients on Windows are legendary for buggering up files by "converting" them from binary to text format.
And don't forget that Macs compound the problem by only using single LF characters rather than the single CR you get on unix. A decent FTP client will usually warn you if you are using the wrong text/binary settings though.
The solution where I work was to install a script on the CVS server that checks line endings on commit. They have to be consistent throughout a given file or the commit is rejected and you have to fix it before trying again. We do the same for tabs in source files after historical problems with mixed tabs and spaces.
1) Treating text files differently from binary files is not a Windows-ism. FTP has two transfer modes - binary and text, and it's people who download binary files in text mode that have problems, regardless of operating system version.
2) Unix uses the LF character, not CR character (0x0a). That includes the current MacOS.
3) There's nothing wrong with having separate carriage return and linefeed characters. Using only the latter is a poorly-conceived attempt to reduce the size of text files, not the result of a sensible decision. It's Unix and its derivatives that's screwed up, not DOS and its derivatives. Consider that all Internet RFCs define line terminators as a CR/LF pair (0x0d0a), regardless of the operating system.