T
@tgape said:Also, depending on how old those Macs are, and how old their software is... IIRC, MacOS prior to 10.x did a particularly 'clever' stupidism of flipping the meaning of '\r' and '\n', as an attempt to make porting C applications easier. I know they fixed that eventually, but I don't know if they fixed it in 10.0.0, or later.
Disclaimer: I know *somebody* did that stupidism, but I'm not 100% certain it was Apple. I can't think of any other candidates, however.
Macs just used CR to mean "end of paragraph" and replaced LF with a rectangle, or ignored it, depending on the typeface being used.
The Mac OS, until Mac OS X, had no internal text-based scheme for dealing with the OS, and thus no cursor control system at all. (If you never need to manipulate a cursor, there is no need for differentiation between CR and LF.) With Mac OS X, Apple completely abandoned the old Mac OS innards -- Mac OS X looks vaguely like the old Mac OS, but underneath, it's Nextstep's BSD Mach kernel. Really, the only reason 10.0 was the Mac OS is because Apple said it was. About 75% of what you knew about the "Classic" Mac OS is wrong on Mac OS X, and the remaining 25% is usually because Apple winched in a compatibility layer to keep existing Mac owners from rebelling.
The irony of all this is that the most logical system of dealing with cursor control is (though it galls me to say this) the one in DOS and Windows. "Carriage Return" and "Line Feed" come from typewriters and teletypes: LF meant move down one line, CR means move to the first position in the line without moving vertically. To start a new line would require both a CR and an LF. (The oldest typewriters had a lever you had to push to advance a line every time you pressed return. You might argue that since later typewriters changed the "return" key to do both at once, the Windows/DOS system is not valid. But in that case, the Mac had the right model by using just CR, and it's the Unix-y LF that is in the wrong.)
Theoretically, this is all moot, because we're all supposed to be using Unicode for text these days, and Unicode has both a line separator and a paragraph separator character (0x2028 and 0x2029) which ought to settle the question by making the old incompatible system obsolete. But almost nobody uses the Unicode versions, and many Unicode implementations can't interpret them properly anyway, so we all get to argue over CR and LF, apparently for all eternity.