리눅스가 왜 LF를 개행 문자로 사용합니까?

87

내가 아는 한, 모든 운영 체제에는 EOL (End of Line) 문자를 표시하는 다른 방법이 있습니다. 상업용 운영 체제는 EOL에 캐리지 리턴을 사용합니다 (Windows에서는 캐리지 리턴 및 줄 바꿈, Mac에서만 캐리지 리턴). 반면에 Linux는 EOL에 줄 바꿈 만 사용합니다.

Linux가 EOL에 캐리지 리턴을 사용하지 않는 이유는 무엇입니까 (대신 줄 바꿈 만)?

files history newlines

— 바 가스 산자야
소스

77

Mac은 OS X 이전에 CR을 사용하지 않았습니다. 현재 * nix 스타일 LF를 사용하고 있습니다.

— B Layer

33

나는 많은 상용 Unixy OS가 있거나 있다고 생각합니다.

— ilkkachu

20

Wikipedia에 설명되어 있습니다. 기본적으로 지난 60 년대 (Linux에 영감을 불어 넣은 Unix에 영감을 주었던) Multics는 텔레타이프 장치의 한계로 인해 텍스트 인코딩이 방해받지 않도록 추상화 수준을 추가하여 두 문자로 줄 바꿈을 인코딩 할 필요가 없었습니다 (더 적은 물론 50 년 후의 감각).

— Stéphane Chazelas

74

두 번째 단락은 유효한 질문이지만 첫 번째 단락은 지나치게 단순화되고 명백한 오류로 가득 차서 익사 할 수 있습니다. 응답자들은 질문에 도달하기 전에 iffy 및 잘못된 전제를 수정해야합니다.

— JdeBP

21

뭐? Linux는 UNIX라는 상용 OS 표준에 대한 무료 근사치입니다. 유닉스 호환 시스템은 당시 많은 돈이 들었고 오늘날에도 여전히 돈이 듭니다.

— 잘못된 표현

334

Windows는 CRLFMS-DOS에서 상속했기 때문에 사용합니다 .

MS-DOS CRLF는 이미 사용중인 CP / M에서 영감을 얻었으므로 사용 CRLF합니다.

CRLF텔레타이프에 인쇄 된 줄을 끝내는 방법이기 때문에 CP / M과 80 년대 및 그 이전의 많은 운영 체제가 사용 되었습니다. 사전 처리가 적거나 필요하지 않기 때문에 파일 인쇄가 간단 해졌습니다. 단일 문자를 사용할 수 없도록하는 기계적 요구 사항도있었습니다. 캐리지가 돌아가고 인자 판이 돌아가는 데 약간의 시간 이 걸릴 수 있습니다 .

Gnu / Linux는 LF유닉스 클론 이기 때문에 사용합니다 . ¹

Unix LF는 처음부터 공간을 절약하고 표준적인 끝까지 표준화하기 위해 단일 문자를 사용했습니다. 두 문자를 사용하면 비효율적이고 모호했습니다. 이 선택은 1964 년 초에 사용했던 Multics에서 상속되었습니다. 메모리, 스토리지, CPU 전력 및 대역폭은 매우 희박하므로 한 줄에 1 바이트를 절약하는 것이 좋습니다. 파일을 인쇄 할 때 드라이버가 줄 바꿈 (줄 바꾸기)을 대상 장치에 필요한 제어 문자로 변환했습니다.

LFCR후자는 여전히 특정 용도로 사용 되었기 때문에 선호되었습니다 . 인쇄 된 문자를 같은 줄의 시작 부분으로 재배치함으로써 이미 입력 된 문자를 과잉 공격 할 수있었습니다.

Apple은 처음에 단일 문자를 사용하기로 결정했지만 어떤 이유로 다른 문자를 선택했습니다 CR. BSD 인터페이스로 전환하면로 이동했습니다 LF.

이러한 선택은 OS가 상업적인지 아닌지와 관련이 없습니다.

¹ 이것은 귀하의 질문에 대한 답변입니다.

— 젤리아 그레
소스

20

Multics는 현대식 ISO / IEC 646과 일치하여 줄 바꿈을 사용했으며, 한 문자 표현이 필요한 경우 단일 문자로 캐리지 리턴과 줄 바꿈을 모두 나타내는 방법으로 규정했습니다.

— JdeBP

10

하나의 캐릭터를 선택하는 진정한 이유는 공간을 절약하기위한 것입니다. 실제 이유는 출력 장치 (터미널 등)와 독립적 인 단일 개행 문자 를 정의하는 것이 었습니다 . 그런 다음 터미널 (또는 유사한) 드라이버는 개행을 적절한 제어 문자 시퀀스 (일반적으로 CR LF)로 변환합니다. 이것은 문자열로 프로그래밍 할 때 좋은 추상화를 가능하게합니다. 개행은 \n특정 출력 장치와 독립적으로 단일로 표시됩니다 .

— Johan Myréen

14

그럼에도 불구하고, Saltzer와 Ossanna ( Multics의 원격 터미널 문자 스트림 처리)에 의한 1970 년 논문 은 장치 독립성 이 그 이유 라는 것을 분명히 알 수 있습니다.

— JdeBP

3

@JdeBP이 백서에서는 원격 터미널로 (부터) 전달되는 문자 스트림을 표준 형식으로 축소 하는 것이이 백서 의 주제입니다 . 표준 형식으로 줄이면 공간을 절약 할 수 있습니다. 다르게 표현하자면, 두 문자를 사용하는 것은 비효율적이고 모호한 공간 낭비였습니다.

— jlliagre 2014

46

그리고 텔레타이프는 비 전기 타자기에서 이것을 얻었습니다. CR-LF는 왼쪽의 레버를 누를 때 취하는 기계적 동작을 나타냅니다. 인자 판 (롤러)을 오른쪽으로 끝까지 고정시키는 "캐리지"를 반환하고 (키 스트라이크를 왼쪽의 첫 번째 위치에 놓음) 인자 판을 한 줄 높이 회전하여 다음 입력 가능한 줄로 이동합니다. 예, 여기에 나이를 분명히 보여주고 있습니다.

— cdkMoose

17

"Newline"에 관한 Wikipedia 기사는 1964 년에 MultiNL에 대한 줄 종결 자 (또는 구분자)로서 NL의 선택을 추적합니다. 불행히도 기사에는 출처에 대한 인용이 거의 없지만 이것이 옳다는 것을 의심 할 이유는 없습니다. CR-LF에 비해이 선택의 두 가지 분명한 이점은 공간 절약과 장치 독립성입니다.

주요 대안 인 CR-LF는 텔레타이프 머신에서 용지 캐리지를 물리적으로 이동시키는 데 사용되는 제어 코드에서 유래합니다. CR은 캐리지를 홈 위치로 되돌리고 LF는 용지 롤러를 회전시켜 인쇄 위치를 아래로 이동합니다 선. 두 제어 문자는 ITA2 코드에 나타나며 1924 년으로 거슬러 올라가 여전히 사용 중입니다 (위키 백과 참조). 분명히 ITA2는 1901 년의 Baudot 코드의 Murray 변형에서 가져온 것입니다.

젊은 독자에게는 메인 프레임 전통에 줄 바꿈 문자가 없었 음을 주목할 가치가 있습니다. 오히려 파일은 고정 길이 (펀칭 카드를 기준으로 80 자) 또는 가변 길이 인 일련의 레코드였습니다. 가변 길이 레코드는 일반적으로 각 레코드 시작시 문자 수와 함께 저장되었습니다. 각각 임의의 이진 컨텐츠를 포함하는 일련의 가변 길이 레코드로 구성된 메인 프레임 파일이있는 경우이를 손실없이 UNIX 스타일 파일로 변환하는 것은 까다로운 변환 일 수 있습니다.

물론 리눅스는 유닉스를 재 구현 한 것이었고, 유닉스는 많은 디자인 결정을 Multics에서 가져 왔기 때문에 1964 년에 결정이 내려진 것처럼 보인다.

— 사용자
소스

12

다른 답변들은 상속 체인을 1960 년대와 텔레타이프로 거슬러 올라갑니다. 그러나 그들이 다루지 않은 한 가지 측면이 있습니다.

텔레타이프 시대에는 오버 스트라이킹 (overstriking)이라고 불리는 것이 바람직한 경우가있었습니다. 암호를 지우는 것은 불가능했기 때문에 과다 공격은 때때로 암호를 가리기 위해 사용되었습니다. 다른 경우에는 글꼴에없는 기호를 얻기 위해 과도하게 시도했습니다. 예를 들어, 문자 O와 슬래시는 새 심볼을 생성합니다.
백 스페이스 (backspace)가 사용 되기는했지만 줄 바꿈없이 캐리지 리턴 (carriage return)을 넣어 오버 스트리킹을 달성했습니다. 이러한 이유로 유닉스 사람들은 캐리지 리턴을 줄 구분 기호로 사용하지 않고 대신 줄 바꿈을 선택했습니다. 이것은 CRLF 규칙을 사용하여 작성된 텍스트를 읽는 데에도 효과적이었습니다. CR이 삼키고 LF가 분리기가됩니다.

— 월터 미티
소스

이 정확한 기억에 감사합니다. 프린터에서 백 스페이스 및 캐리지 리턴 (단독)을 사용하여 굵은 체 또는 밑줄 친 문자를 생성했습니다. 그리고 기원으로 돌아 가기 위해,이 두 명령은 1930 년에 이미 존재하여 "캐리지"를 가장 왼쪽 위치로 "복귀"시키거나 "새 줄"의 도움으로 새로운 줄을 시작할 수 있도록했습니다. 롤러를 1 단 회전시키는 키. en.wikipedia.org/wiki/IBM_Electric_typewriter를 참조하십시오 . 따라서 "CR"+ "LF"는 컴퓨터 기록 이전에 데이트하고 있습니다.

— dan

일부 텔레타이프에서는 다음 인쇄 문자가 도착하기 전에 캐리지가 완전히 순환 될 수 있도록 CR 다음에 비 인쇄 문자가 있어야하고, 백 스페이스를 전혀 지원하지 않아 CR 이후에 LF를 전송해야한다는 텔레타이프도 주목할 가치가 있습니다. 비용이 들지 않았으며 중복 인쇄를 수행하는 유일한 방법은 CR을 사용하는 것입니다.

— supercat

"텔레타이프의 날"은 컴퓨터 시대 이전에 시작됩니다. 1960 년대에는 많은 컴퓨터가 운영자를위한 콘솔 텔레타이프를 사용했으며 ASCII를 문자 세트로 사용했습니다.

— Walter Mitty

7

당신은 C 언어, 리눅스 및 모든 POSIX-준수 또는 POSIX 틱 시스템이 이유에 대한 질문에 역사적 질문을 번역 할 수 있지만 있어야 사용 LF(또는 C의 어떤 적어도 '\n'문자가) 새로운 라인과 교차의 결과입니다 C 및 POSIX의 요구 사항. C는 "텍스트 파일"과 "바이너리 파일을"수 있지만 차이 (사실 텍스트 파일 기록을 기반뿐만 아니라, 라인 기록의 순서로 구성 할 수 있습니다와 같은 덜 이국적인 것들이 데 '\n'번역에 /에서 CR/ LFDOS / Windows에서 같은 )에서 POSIX는 텍스트와 이진 모드가 동일하게 작동하도록 요구합니다. 이것은 주로 명령 행 도구가cat강력하고 유용하다. 바이너리 만 사용하거나 텍스트 만 사용하지만 둘 다 사용하지 않는 경우에는 훨씬 적습니다.

— 아르 자형..
소스

13

이 선택은 POSIX보다 몇 년 전입니다. jlliagre의 답변에서 언급했듯이 Unics의 시작 부분으로 돌아가 Multics에서 복사했습니다.

— Barmar

4

Linux에서 선택한 것이 POSIX보다 몇 년 전부터는 아닙니다. 물론 POSIX는 기존 관행이 무엇인지를 체계화했습니다.

— R ..

리눅스에 관한 한, 처음부터 진정한 선택은 없었습니다. Linux에서 사용하는 Gnu 표준 라이브러리는 POSIX에 현대적이며 Unix 시스템에서 개발, 테스트 및 사용 되었기 때문에 명백한 호환성을 위해 처음부터 줄 바꿈을 사용했습니다. Linux 커널은 표준 C 라이브러리 (GNU 또는 기타)에 Unix와 같은 시스템 호출을 제공하도록 설계되었으며, 텍스트 파일과 이진 파일을 다르게 처리하는 데 필요한 복잡성을 추가하는 것은 지나친 것이며 기존 코드와의 호환성을 손상시킵니다. 토발즈의 말이 맞지 않았을 것입니다.

— jlliagre

@jlliagre : 임의의 무료 비 호환성보다는 기존 관행과 호환되는 것을 만드는 것이 여전히 선택이었습니다. Linux의 성공을 가정 할 때 이것이 선택이 아니라고 말할 수 있습니다. 많은 사람들이 장난감 애호가 OS를 무심코 선택의 여지가 가득한 곳으로 만들고 어디로도 가지 않습니다.

— R ..

@RI는 리눅스가 커널 일 뿐이며 GNU가 작동하기 위해 필수적으로 필요하다는 것을 의미합니다. 줄 바꿈 선택은 Linux가 작성되기 오래 전에 만들어 졌기 때문에 Linux와 관련이 없습니다. 다양한 Linux 릴리스에는 다소 무질서한 선택이 많았지 만 Linux가 성공하는 것을 막지는 못했습니다. 이러한 선택 중 많은 부분이 나중에 다시 검토 되었기 때문일 수 있습니다.

— jlliagre 2016