[TUHS] Why is \n 012?

[TUHS] Why is \n 012?

[Greg 'groggy' Lehey]

A thing that has puzzled me almost for ever is why the newline
character in C is 012 and not 015.  Does anybody have any insight?

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20030309/8ad517aa/attachment.sig>

[TUHS] Why is \n 012?

[Greg Haerr]

> A thing that has puzzled me almost for ever is why the newline
> character in C is 012 and not 015.  Does anybody have any insight?

Well, my take on this is that C was developed with UNIX,
of course, and UNIX early on decided to use a single
character rather than a two-char (CRLF) sequence for
end-of-lines.  So, since the CR was already in use for 
the leading char in the two-char sequence, it made it a lot
easier to use the LF character for the single newline, so
programs wouldn't always have to be checking a second
character...

Regards,

Greg

[TUHS] Why is \n 012?

[M. Warner Losh]

In message: <040b01c2e5f0$03000580$6401a8c0 at gregnewport>
            "Greg Haerr" <greg at censoft.com> writes:
: > A thing that has puzzled me almost for ever is why the newline
: > character in C is 012 and not 015.  Does anybody have any insight?
: 
: Well, my take on this is that C was developed with UNIX,
: of course, and UNIX early on decided to use a single
: character rather than a two-char (CRLF) sequence for
: end-of-lines.  So, since the CR was already in use for 
: the leading char in the two-char sequence, it made it a lot
: easier to use the LF character for the single newline, so
: programs wouldn't always have to be checking a second
: character...

Also, it is not possible to do overstriking w/o <BS> if you can't use
<CR> for the task.

Warner

[TUHS] Why is \n 012?

[Dennis Ritchie]

Lehey wondered,

 > A thing that has puzzled me almost for ever is why the newline
 > character in C is 012 and not 015.  Does anybody have any insight?

And Haerr speculated 
 > Well, my take on this is that C was developed with UNIX,
 > of course, and UNIX early on decided to use a single
 > character rather than a two-char (CRLF) sequence for
 > end-of-lines...

This came via Unix from Multics.  My Multics
Programmers' Manual (1969) says, in reference
to its use of the ASCII character set: "Reference:
USA Standard X3.4-1967," and describes the LF
character, with code octal 012, "New Line.
Move carriage to the left edge of the next
line.... ASCII LF is used for this function."

I believe that either this or some other version
of ASCII standard blessed (or condoned) one
of the interpretations of the 012 character
for the new-line function.  However, I haven't
turned up hard evidence of this, despite several
conversations with Eric Fischer, who has
kept track of various versions of the standards.

In the event, various of the terminals used early
on did implement the NL function.  E.g. the
IBM 1050 and 2741 terminals (decidedly
non-ASCII) had a new-line function, like
a typewriter, no CR, but sometimes an
"Index" character that moved the paper
but not the printing element.  The TTY 37
had an optional interpretation of 012 as
NL.  Of course, other terminals required
separate CR and LF characters.

The choice of a single character to separate
lines still seems wise if you're using a byte-stream
model.

	Dennis