The default line end is still CR in finder based Mac OS X applications.
- joey
At 06:04 +0800 2006/05/19, Chris Burke wrote:
June Kim wrote:
Python's way of solving this nasty problem is laying an abstract layer
at the bottom: the universal newline feature.
http://www.python.org/dev/peps/pep-0278/
When you open a file and read, all LF/CR/CRLF are translated into an
identical entity, universal newline (\n).
When programming, the programmer doesn't need to consider which
platform he/she is on, or which platform the program will be used on.
2006/5/18, Miller, Raul D <[EMAIL PROTECTED]>:
The line delimiter for unix is LF.
The line delimiter from the PC is CRLF.
The line delimiter for mac is CR.
Sometimes a trailing fragment (after the last end of line)
in a text file is treated as a valid line. Sometimes,
it's not.
Conceptually, you could write a routine which accepts all
these standards.
The "string" versions of the file functions do this conversion. For
example, fread reads the raw file, while freads assumes the file is
text, and converts any CRLF or CR to LF, and ensures the result ends in
LF. It would be useful to have this capability in the file foreigns, as
in Python.
Do we need to worry about the CR delimiter in the old Mac? I thought
this was obsolete now, if not the new functions we discussed need to
take this into account - right now they assume sentences end in LF.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
