Re: Ascii number of return
Re: Ascii number of return
- Subject: Re: Ascii number of return
- From: "Mark J. Reed" <email@hidden>
- Date: Fri, 23 Oct 2009 10:35:38 -0400
On Thu, Oct 22, 2009 at 6:13 PM, Doug McNutt <email@hidden> wrote:
> Somewhere there is a "standard", perhaps ASCII itself, that the
> escaped r and n are supposed to make return and linefeed behave the
> way they should in a system-independent way.
That's not ASCII - it only specifies the original behavior and short
and long names. ASCII was created for teletypes, and CR sent the
print head back to the start of the line without advancing the platen,
while LF advanced the platen without moving the print head. So you
needed to send both to get a "new line". But when messages started
being stored rather than just sent immediately, using two whole bytes
to indicate EOL was exorbitant, so the sequence was abbreviated.
Naturally, different computer makers picked different halves of the
sequence to represent EOL, when there was even an in-band
representation at all - representing text files as structured data
with one record per line was pretty common at one time. UNIX's file
storage philosophy of "it's all just bytes" was pretty groundbreaking.
Anyway. The backslash escapes don't come from ASCII, but from the C
programming language. C requires that '\n' map to whatever the heck
the target system's newline convention is, including "make a new line
record in the structured data file". That's why it's called "newline"
rather than "linefeed" - the fact that it's usually linefeed comes
from UNIX, where a single linefeed is the newline convention.
But at least ANSI C also requires that in-memory characters and
strings follow the UNIX convention: "\n" is always exactly one byte
with decimal value 10. So even on MPW, these should be true:
'\n' == 10
'\r' == 13
Even though when you actually print those characters out, you'll get
the opposite values on the output stream.
--
Mark J. Reed <email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden