[Mark]
... The case for abandoning the CRTL's text mode gets stronger and stronger!
[Gordon]
If you're tying this in with Tim's Icon worship,
note that in these days of LANS, the issue is yet more complex. It would be dandy if I could read text any old text file and have it look sane, but I may be writing it to a different machine without any way of knowing
Icon inherits stdio behavior-- for the most part --too. It does define its own mode string characters, though (like "t" for translated and "u" for untranslated); Icon has been ported to platforms that can't even spell libc, let alone support it. that. So where's the problem? No matter *what* machine you end up on, Python could read the thing fine. Or are you assuming some fantasy world in which people sometimes run software other than Python <wink>? Caveat: give the C std a close reading. It guarantees much less about text mode than anyone who hasn't studied it would believe; e.g., text mode doesn't guarantee to preserve chars with the high bit set, or most control chars either (MS's treatment of CTRL-Z as EOF under text mode conforms to the std!). Also doesn't guarantee to preserve a line-- even if composed of nothing but printable chars --if it's longer than 509(!) characters. That's what I mean when I say stdio's text mode is a bad joke.
When I bother to manipulate these things, I usually choose to use *nix style text files. But I don't deal with Macs, and the only common Windows tool that can't deal with plain \n is Notepad.
I generally create text files in binary mode, faking the \n convention by hand. Of course, I didn't do this before I became a Windows Guy <0.5 wink>.
and-stripcr.py-is-everywhere-available-on-my-Linux-box-ly y'rs
A plug for my linefix.py (Python FTP contrib, under System), which converts among Unix/Windows/Mac in any direction (by default, from any to Unix). who-needs-linux-when-there's-a-python-in-the-window-ly y'rs - tim