is the value of CR really platform dependant?

Richard Gaskin ambassador at
Fri Aug 30 13:07:16 EDT 2002

Bill Vlahos wrote:

> On Friday, August 30, 2002, at 09:48  AM, Richard Gaskin wrote:
>> As text:
>> open file tMyFile for read
>> - OR -
>> open file tMyFile for text read
>> - OR -
>> put url ("file:"&tMyFile) into tMyData
>> As binary:
>> open file tMyFile for binary read
>> - OR -
>> put url ("binfile:"&tMyFile) into tMyData
>> If you read in text mode, the line endings are handled for you
>> automatically
>> on all platforms.
> Are you saying that if I use "open file tMyFile for text read" all the
> platforms will do the right conversion regardless of the format of the
> text file (LF, CR, or CRLF)?
> Using the get URL("file:"&tMyFile) Linux and Solaris platforms don't
> work properly with CR delimited text files. What I have found is that
> if the text file is unix formatted linefeed delimited, then all of the
> platforms can read them correctly. It was a pain to figure this out.
> If the open...for text read is the does everything right, then it is
> the holy grail we have been looking for.
> Do I have it correct?

I can only describe the intent. :)  Text mode should convert
platform-specific line endings to the UNIX standard ( a single linefeed
character, ASCII 10, denoted by the constant "cr" or "return").  Writing
should take care of that in reverse:  the engine's UNIX line endings become
native to the OS the file is being written on (CRLF for Win, ASCII 13 for
Mac OS).

If the engine is doing anything different in text mode, I would consider it
a bug unless there's a benefit to such an exception that I'm not seeing.

 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 2.0: Publish any database on any site
 Ambassador at
 Tel: 323-225-3717                       AIM: FourthWorldInc

More information about the Use-livecode mailing list