다른 플랫폼에서 끝나는 다른 라인의 역사적 이유

Question

DOS/Windows와 Mac이 n 대신 라인 엔딩에 r n 및 r을 사용하기로 결정한 이유는 무엇입니까? Unix와 "다른"결과를 얻으려고 했습니까?

그리고 이제 Mac OS X가 Unix (-like)이므로 Apple은 n에서 n으로 전환 했습니까?

Answer 1

DOS는 CP/M에서 CR-LF 라인 엔딩 ( r n, ASCII 문자를 명시 적으로 만드는 것)을 상속 받았습니다. CP/M은 CP/M 디자이너 Gary Kildall에 영향을 미치는 다양한 DEC 운영 체제에서 물려 받았습니다.

CR-LF가 텔레 타입 기계가 인쇄 헤드를 왼쪽 여백으로 반환하고 (CR = 캐리지 리턴)로 반환 한 다음 다음 줄 (LF = 라인 피드)으로 이동하도록 사용되었습니다.

UNIX 직원은 장치 드라이버에서이를 처리하고 필요할 때 필요한 경우 LF를 CR-LF로 번역하여 필요한 장치로 출력했습니다.

그리고 당신이 추측 한대로, Mac OS X는 이제 LF를 사용합니다.

Answer 2

정말 @mark 해리슨에 추가 ...

UNIX를 말하는 사람들은 "프로그래머가 지정한 텍스트를 출력하는 것만"이라고 말하는 반면 DOS는 분명한 잘못입니다. 또한 DOS가 EOF 캐릭터를 볼 때 DOS가 EOF를 표시하는 것은 어리석은 일이라고 주장하며, 그 캐릭터가 정확히 무엇인지에 대한 의문을 제기합니다.

텍스트 파일 라인 엔딩에 대한 진정한 협약은 없으며 플랫폼 별 규칙 만 있습니다. 결국, CR-LF, CR 및 LF조차도 사용될 유일한 라인 엔드 규칙이 아니며 ASCII는 결코 유일한 문자 세트조차 없었습니다. 문제는 C 표준 라이브러리 및 런타임으로,이 플랫폼 의존적 세부 사항을 추상화시키지 못했습니다. 다른 3 세대 언어 (예 : Pascal 및 심지어 기본)는 적어도 어느 정도 관리했습니다. 이로 인해 C 컴파일러가 다른 플랫폼을 위해 작성되었을 때 기존 소스 코드 및 서적과의 호환성을 달성하기 위해 런타임 라이브러리 해킹이 필요했습니다.

실제로, 사용자는 일반적으로 CR LF 라인 끝이 필요한 ASCII 터미널에 앉아 있었기 때문에 원래 콘솔 I/O에 대한 문자열 번역이 필요한 유닉스와 멀티 틱입니다. 그러나이 번역은 장치 드라이버에서 수행되었습니다. 목표는 하나의 컨벤션을 채택하고 저장된 텍스트 파일을 고수하는 것이 더 낫다고 가정 할 때 장치별로 추상화하는 것이 었습니다.

C 텍스트 I/O 해킹은 원칙적으로 Cygwin이 현재하는 일과 유사하며 Linux Runtimes를 해킹하고 Windows에서 예상 할 수 있습니다. Unix -Alikes로 바꾸려는 실제 역사가 있지만 Linux를 Windows로 바꾸는 와인도 있습니다. 이상하게도, 당신은 Cygwin FAQ (인터넷 아카이브 링크 추가 2013- 페이지가 더 이상 존재하지 않습니다). 어쩌면 그것은 기본적으로 비판하는 일을하고 있지만 훨씬 더 큰 규모로 ;-) 그것은 유머 감각일지도 모른다.

C ++ 표준 라이브러리 (구현 된 플랫폼이든)는 ioStreams를 사용 하여이 문제를 피하며 추상적 인 원정 라인이 끝납니다. 생산을 위해서, 그것은 나에게 잘 어울립니다. 입력하려면 더 많은 제어가 필요하므로 문자별로 해석하거나 스캐너 생성기를 사용합니다.

[편집하다 위의 끔찍한 주장은 사실이 아니며 결코 그렇지 않은 것으로 밝혀졌습니다. 그만큼 std::endl 말 그대로 a로 번역됩니다 \n 그리고 플러시. 그만큼 \n 정확히 동일합니다 \n 당신은 C에 들어갑니다 - 그것은 "새로운 라인"이라고 불리는 경향이 있지만 실제로는 ASCII 라인 피드 문자이므로 필요한 경우 런타임으로 번역됩니다. 거짓 가정이 어떻게 그렇게 뿌리를 내릴 수 있는지 재미있게 생각하지 않습니다.

내 POV의 가장 큰 비난은 C와 함께 있지만 C만이 다른 플랫폼으로의 이동을 예상하지 못하는 유일한 프로젝트는 아닙니다. Blaming Bill Gates는 단지 견과입니다. 그가 한 것은 당시 인기있는 CP/M의 변형을 사서 연마하는 것입니다. 실제로, 그것은 단지 역사 일뿐입니다. 우리가 대부분의 텍스트 파일에서 문자 코드 128 ~ 255를 모르는 것과 같은 이유입니다. 3 개의 라인 엔드 컨벤션 모두에 대처하기 쉽다는 점을 감안할 때 일부 개발자는 여전히 "내 플랫폼 컨벤션은 한 가지 진정한 방법이며, 나는 당신이 그것을 좋아하는지"태도를 강요 할 것입니다.

또한 - 유니 코드 라인 분리기 CodePoint U+2028이 향후 텍스트 파일에서 이러한 모든 규칙을 대체합니까? ;-)

Answer 3

Wikipedia의 라인 엔딩에 대한 다소 긴 기사가 있습니다. "히스토리"섹션은 귀하의 질문의 적어도 일부에 답변합니다. http://en.wikipedia.org/wiki/newline#history

Answer 4

CRLF가 인터넷 표준이라는 점에 주목하는 것은 흥미 롭습니다. 즉, 라인 지향적 인 모든 표준 인터넷 프로토콜은 CRLF를 사용합니다. SMTP, POP, IMAP, NNTP 등 .. 이메일 본문은 CRLF에 의해 종료 된 줄로 구성됩니다.