Constant command

[Jim Ault]

On Oct 14, 2010, at 3:15 PM, Bob Sneidar wrote:

> Wha??? That just makes no sense at all! A CR should be chr(13) and  
> LF should be chr(10). Period. If in Revolution it is not, then I  
> need to go back and edit a whole lot of scripts!
>
> Bob
>
unix line endings are (10)
mac line endings are (13)
window line endings are (10)(13)
--  both chars in that sequence == one line ending
This has been true since the earliest days of each platform.

If your stack or app or exe is running on a different platform, the  
engine tries to make the conversion for you, so you don't need to do  
any IF-loops.

Word processors like TextWrangler, BBEdit not only do the text file  
translation automatically, they allow the user to force file  
conventions.

Binary files (such as .zip  .jpg .avi ) are not converted, nor would  
it make sense to do so.

Forcing a format becomes necessary when editing files, such as OnRev  
scripts, when line ending conventions have to be strictly observed  
regardless of the editing platform.
Another example of non-conversion is receiving log info from an FTP  
server.
Yet another example of non-conversion is receiving data over a socket,  
such as TCP or UDP.

Hope this helps.
>
> On Oct 14, 2010, at 2:23 PM, Peter Brigham MD wrote:
>
>> Just noticed, in reading the dictionary on "constant" --
>>
>> CR = return = LF = linefeed = numtochar(10)
>> but
>> "CRLF" is listed as "Equivalent to a carriage return (ASCII 13,  
>> Control-M) followed by a line feed (ASCII 10, Control-J)," implying  
>> that "carriage return" = numtochar(13) <> linefeed. Apparently,  
>> "carriage return" <> "CR" ... WTF?
>>
>> Practically speaking, I never think about this, and always use cr  
>> for delimiting lines and trust to the engine to translate between  
>> platforms -- but the definitions and terminology are certainly  
>> inconsistent. I'm glad I don't *have* to keep it straight....
>>
>> -- Peter

Jim Ault
Las Vegas