Text files driving me mad

[Dar Scott]

On Tuesday, June 4, 2002, at 09:41 AM, Bill Vlahos wrote:

> If I get URL (file:...text file) I get various results depending 
> on which platform as it sees and knows what to do with cr, lf, or 
> crlf. My file is currently cr delimited which works fine with Macs 
> and Windows but not with Linux. I put in an option to replace cr 
> with lf but it doesn't seem to work with Linux. In looking at the 
> Rev docs "return" is a synonym for "lf" so perhaps that is my 
> problem. I will try it today with replacing ASCII 13 instead of 
> "return". However, all of this seems like a hack when the get URL 
> http works all by itself.

Do you have control over this file?  Do other applications need to 
look at it?  If yes and no, then just use linefeed and get it 
binary.

If you need to read native files, I would bring them in with 
binfile and then do the conversion.  (I would be interested in why 
reading as text does not work in this case.)

As Sarah said,
> If you check the Transcript dictionary entry for CR, down the 
> bottom you will see this:
> "The line feed character is the standard end-of-line delimiter on 
> Unix systems. The end-of-line delimiter for Mac OS systems is a 
> carriage return, and the end-of-line delimiter for Windows systems 
> is a carriage return followed by a line feed."

However, on Windows I have seen CRLFLF instead of CRLFCRLF for 
double spacing.

You are right that you have to watch out for cr not being ASCII 13.

You might try a system check and convert.  Or you might try 
something like this:
Convert CRLF to something special.
Convert carriage return to linefeed.
Convert something special to linefeed.

This kind of problem also applies to reading from a process, only 
there binary is not an option; data is lost.

Dar Scott