Windows: end of line is \r\n Unix: end of line is \n BUT, these days Windows programs have to deal with text files written on Unix, and Unix programs have to deal with text files written on Windows, especially when mounting networked file systems using things like NFS and Samba. Even when working with local files, there isn't any way for a program on either system to tell where a text file originally came from. So programs on BOTH systems really need to deal with BOTH conventions. We can go further: the Internet convention for end of line is, sadly, and somewhat accidentally, the same as the Windows convention. It's a right pain sometimes having to remember to stuff \r into things on UNIX so that it will go the right way down the wire (according to the strict protocol) to a program on the other end whose designer really wished the \r weren't there, but that's the world we live in. According to the ASCII standard, it was fully legitimate to use backspace and carriage return to get over-striking (which is why ASCII includes oddities such as ^ and ` : they really are for accents, and , did double duty as cedilla, ' as acute accent, =\b/ really was not-equals (as was /\b=), &c). According the the ISO 8859 standard, that's not kosher any more. So there are (on Windows and Unix) no known uses for isolated \r characters. Accordingly, a text mode that simply throws away every \r it comes across will not just be useful on Windows, it will be useful on Unix as well. The old DOS Ctrl-Z convention hasn't been recommended practice on Windows for years, so there's not much point bothering with that.