line endings on OS X

[Bernard Devlin]

I have a problem writing to text files on OS X, and would like to  
determine if it is a defect in Revolution.

If I save a multi-line text file using vi (created pressing the  
return key), or if I do the following:

echo "line 1" > mytextfile.txt
echo "line 2" >> mytextfile.txt

then I can get a 'clean' text file (if I type 'more mytextfile.txt',  
there are no strange '^M' characters where there should be line  
endings).

However, no matter what I put as a line ending using Rev (2.7 or  
2.8), I get the strange '^M' characters if I look at the file using  
either vi or the 'more' command).  I tried using the 'file:' URL  
schema, and 'write to file'.

I've tried all the following as line-endings in Rev on OS X, but NONE  
gives a clean text file:

return
CRLF
numToChar(10)
numToChar(13)

The fact that they all display as '^M' when the text file is viewed  
using OS X command line utilities makes me think there is some weird  
character translation going on between Rev and the file system.

I did the same experiment using Rev 2.8 on Windows.  When I viewed  
the file from a command window, then there were no extraneous '^M'  
characters in Windows.  Furthermore, when I ftp-ed the files to OS X,  
there were no strange ^M characters.  (I know that an Ascii FTP  
transfer between operating sytems will translate end of line  
characters).

If I look at a 'clean' text file on OS X (made e.g. with vi) Rev  
tells me (using charToNum) that the line-ending character is ASCII  
10.  Yet the documentation for Rev says "Different operating systems  
use different characters to mark the end of a line. Mac OS and OS X  
use a return character (ASCII 13), Unix systems use a linefeed  
character (ASCII 10)..."

After spending a couple of hours trying to work out what was going  
on, I finally decided to use binfile as the URL file type.  Now,  
'return', 'CRLF', numToChar(10) all produce a 'clean' file.  NumToChar 
(13) as a line-ending in a binfile still produces '^M' in the final  
file.

Is this a bug?  It certainly seems inconsistent to me.

Bernard