왜 텍스트 파일은 개행으로 끝나야 합니까?

질문자 :Will Robertson

여기 있는 모든 사람은 모든 텍스트 파일이 줄 바꿈으로 끝나야 한다는 격언에 익숙하다고 가정합니다. 나는 이 "규칙"에 대해 몇 년 동안 알고 있었지만 항상 궁금했습니다. 왜죠?

이것이 POSIX 표준이 행을 정의하는 방법이기 때문입니다.

3.206 라인

0개 이상의 비 <newline> 문자와 종료 <newline> 문자의 시퀀스입니다.

따라서 개행 문자로 끝나지 않는 행은 실제 행으로 간주되지 않습니다. 그렇기 때문에 일부 프로그램은 줄 바꿈이 종료되지 않은 파일의 마지막 줄을 처리하는 데 문제가 있습니다.

터미널 에뮬레이터에서 작업할 때 이 지침에는 최소한 한 가지 어려운 이점이 있습니다. 모든 Unix 도구는 이 규칙을 기대하고 함께 작동합니다. cat 파일을 연결할 때 줄 바꿈으로 끝나는 파일은 다음이 없는 파일과 다른 효과를 냅니다.

 $ more a.txt foo $ more b.txt bar $ more c.txt baz $ cat {a,b,c}.txt foo barbaz

그리고 앞의 예에서도 보여주듯이 명령줄에 파일을 표시할 때(예: more 를 통해) 줄바꿈으로 끝나는 파일은 올바른 표시가 됩니다. 부적절하게 종료된 파일은 깨져 보일 수 있습니다(두 번째 줄).

일관성을 위해 이 규칙을 따르는 것이 매우 유용합니다. 그렇지 않으면 기본 Unix 도구를 다룰 때 추가 작업이 발생합니다.

---

다르게 생각하십시오. 줄바꿈으로 끝나지 않는 경우 cat 과 같은 명령을 유용하게 만드는 것은 훨씬 더 어렵습니다. 다음과 같이 파일을 연결하는 명령을 어떻게 만드나요?

1. 각 파일의 시작을 새 줄에 넣습니다. 이는 95%의 시간 동안 원하는 것입니다. 하지만
2. b.txt 와 c.txt 사이의 위의 예에서와 같이 두 파일의 마지막 줄과 첫 번째 줄을 병합할 수 있습니까?

물론 이것은 해결할 수 cat 의 사용법을 cat a.txt --no-newline b.txt c.txt 와 같은 위치 명령줄 인수를 추가하여) 이제 각 개별보다는 명령을 사용해야 합니다. 파일은 다른 파일과 함께 붙여넣는 방법을 제어합니다. 이것은 거의 확실히 편리하지 않습니다.

... 또는 종료되지 않고 계속되어야 하는 행을 표시하기 위해 특수 센티넬 문자를 도입해야 합니다. 글쎄, 이제 반전(줄 종료 문자가 아닌 줄 연속)을 제외하고는 POSIX에서와 같은 상황에 봉착했습니다.

---

_{이제 POSIX와 호환되지 않는 시스템(요즘은 대부분 Windows)에서 요점은 중요하지 않습니다. 파일은 일반적으로 줄 바꿈으로 끝나지 않으며 줄의 (비공식) 정의는 예를 들어 "줄 바꿈으로 구분 된 텍스트"일 수 있습니다. (강조에 주의). 이것은 전적으로 유효합니다. 그러나 구조화된 데이터(예: 프로그래밍 코드)의 경우 구문 분석이 최소한으로 더 복잡해집니다. 일반적으로 이는 구문 분석기를 다시 작성해야 함을 의미합니다. 파서가 원래 POSIX 정의를 염두에 두고 작성된 경우 파서보다 토큰 스트림을 수정하는 것이 더 쉬울 수 있습니다. 즉, 입력 끝에 "인공 개행" 토큰을 추가합니다.}

Konrad Rudolph

각 줄은 마지막 줄을 포함하여 개행 문자로 끝나야 합니다. 일부 프로그램은 줄 바꿈이 종료되지 않은 경우 파일의 마지막 줄을 처리하는 데 문제가 있습니다.

GCC는 파일을 처리 할 수 없기 때문에 그것에 대해하지 경고하지만 표준의 한 부분으로하기 때문에.

C 언어 표준에 따르면 비어 있지 않은 소스 파일은 백슬래시 문자 바로 앞에 오면 안 되는 줄 바꿈 문자로 끝나야 합니다.

이것은 "shall" 절이므로 이 규칙 위반에 대한 진단 메시지를 내보내야 합니다.

이것은 ANSI C 1989 표준의 섹션 2.1.1.2에 있습니다. ISO C 1999 표준(및 아마도 ISO C 1990 표준)의 섹션 5.1.1.2.

참조: GCC/GNU 메일 아카이브 .

Bill the Lizard

이 답변은 의견이 아닌 기술적인 답변에 대한 시도입니다.

POSIX 순수주의자가 되고 싶다면 라인을 다음과 같이 정의합니다.

0개 이상의 비 <newline> 문자와 종료 <newline> 문자의 시퀀스입니다.

출처: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

다음과 같은 불완전한 줄:

파일 끝에 있는 하나 이상의 비 <newline> 문자 시퀀스입니다.

출처: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_195

다음과 같은 텍스트 파일:

0개 이상의 행으로 구성된 문자를 포함하는 파일입니다. 줄에는 NUL 문자가 포함되지 않으며 <newline> 문자를 포함하여 길이가 {LINE_MAX}바이트를 초과할 수 없습니다. POSIX.1-2008은 텍스트 파일과 바이너리 파일을 구분하지 않지만(ISO C 표준 참조), 많은 유틸리티는 텍스트 파일에서 작동할 때 예측 가능하거나 의미 있는 출력만 생성합니다. 이러한 제한이 있는 표준 유틸리티는 항상 STDIN 또는 INPUT FILES 섹션에 "텍스트 파일"을 지정합니다.

출처: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397

다음과 같은 문자열:

첫 번째 null 바이트를 포함하여 종료되는 연속 바이트 시퀀스입니다.

출처: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396

이 다음에서, 우리는 유일한 시간은 우리가 잠재적으로 우리가 파일의 선이나 텍스트 파일이 제로의 조직임을되는 텍스트 파일 (같은 파일의 개념을 다루는 경우 문제의 모든 유형을 발생하는 것을 유도 할 수있다 또는 그 이상의 줄, 그리고 우리가 알고 있는 줄은 <newline>으로 끝나야 합니다).

적절한 사례: wc -l filename .

wc 의 매뉴얼에서 우리는 다음을 읽었습니다.

줄은 <newline> 문자로 구분된 문자열로 정의됩니다.

JavaScript, HTML 및 CSS 파일이 텍스트 파일이라는 의미는 무엇입니까?

브라우저, 최신 IDE 및 기타 프런트 엔드 애플리케이션에서는 EOF에서 EOL을 건너뛰는 데 문제가 없습니다. 응용 프로그램은 파일을 올바르게 구문 분석합니다. 모든 운영 체제가 POSIX 표준을 따르는 것은 아니므로 비 OS 도구(예: 브라우저)가 POSIX 표준(또는 모든 OS 수준 표준)에 따라 파일을 처리하는 것은 비실용적입니다.

결과적으로 EOF의 EOL은 UNIX OS에서 실행되는지 여부에 관계없이 응용 프로그램 수준에서 거의 부정적인 영향을 미치지 않을 것이라고 비교적 확신할 수 있습니다.

이 시점에서 우리는 클라이언트 측에서 JS, HTML, CSS를 다룰 때 EOF에서 EOL을 건너뛰는 것이 안전하다고 자신 있게 말할 수 있습니다. 실제로 <newline>이 포함되지 않은 이러한 파일 중 하나를 축소하는 것이 안전하다고 말할 수 있습니다.

한 단계 더 나아가 NodeJS에 관한 한 POSIX 표준을 준수할 수 없다는 점은 POSIX와 호환되지 않는 환경에서 실행할 수 있다는 점입니다.

그러면 우리에게 무엇이 남습니까? 시스템 수준 도구.

wc 표시된 라인 정의)에 기능을 고수하려는 도구와 관련이 있음을 의미합니다.

그렇더라도 모든 쉘이 자동으로 POSIX를 준수하는 것은 아닙니다. 예를 들어 Bash는 기본적으로 POSIX 동작을 사용하지 않습니다. 이를 활성화하는 스위치가 있습니다: POSIXLY_CORRECT .

EOL의 가치에 대해 생각해 볼 수 있는 <newline>: https://www.rfc-editor.org/old/EOLstory.txt

모든 실용적인 의도와 목적을 위해 툴링 트랙을 유지하면서 다음을 고려해 보겠습니다.

EOL이 없는 파일로 작업해 보겠습니다. 현재 이 예제의 파일은 EOL이 없는 축소된 JavaScript입니다.

 curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o x.js curl http://cdnjs.cloudflare.com/ajax/libs/AniJS/0.5.0/anijs-min.js -o y.js $ cat x.js y.js > z.js -rw-r--r-- 1 milanadamovsky 7905 Aug 14 23:17 x.js -rw-r--r-- 1 milanadamovsky 7905 Aug 14 23:17 y.js -rw-r--r-- 1 milanadamovsky 15810 Aug 14 23:18 z.js

cat 파일 크기는 정확히 개별 부분의 합입니다. JavaScript 파일의 연결이 JS 파일에 대한 문제인 경우 더 적절한 문제는 각 JavaScript 파일을 세미콜론으로 시작하는 것입니다.

사람으로 다른 사람이 스레드에서 언급 : 당신은 무슨 원한다면 cat 출력이 하나의 라인 대신이됩니다 두 개의 파일을? 즉, cat 는 해야 할 일을 합니다.

man of cat 은 <newline>이 아닌 EOF까지의 읽기 입력만 언급합니다. cat 의 -n 스위치는 또한 <newline> 종료 되지 않은 줄(또는 불완전한 줄 )을 한 줄로 인쇄 합니다. 이는 카운트가 1 에서 시작하기 때문입니다( man 에 따르면).

-n 1부터 시작하여 출력 라인에 번호를 매깁니다.

이제 POSIX가 line 을 정의하는 방법을 이해했으므로 이 동작은 모호하거나 실제로는 비준수입니다.

주어진 도구의 목적과 규정 준수를 이해하면 EOL로 파일을 종료하는 것이 얼마나 중요한지 결정하는 데 도움이 됩니다. C, C++, Java(JAR) 등에서 일부 표준은 유효성을 위해 줄 바꿈을 지시합니다. JS, HTML, CSS에는 그러한 표준이 없습니다.

예를 들어, wc -l filename awk '{x++}END{ print x}' filename 사용할 수 있으며, 우리가 작성하지 않은 처리하려는 파일에 의해 작업의 성공이 위태로워지지 않도록 안심하십시오( 예를 들어, 타사 라이브러리 등의 축소 된 JS로 우리 curl D) - 우리의 의도는 POSIX 호환 의미에서 선을 계산 진정했다 않는.

결론

JS, HTML 및 CSS와 같은 특정 텍스트 파일에 대해 EOF에서 EOL을 건너뛰는 것이 부정적인 영향을 미치는 실제 사용 사례는 거의 없습니다. 존재하는 <newline>에 의존하는 경우, 우리는 우리가 작성한 파일에 대해서만 도구의 신뢰성을 제한하고 타사 파일에 의해 발생하는 잠재적 오류에 대해 스스로를 개방합니다.

이야기의 교훈: EOF에서 EOL에 의존하는 약점이 없는 엔지니어링 툴링.

EOL을 건너뛰는 것이 어떻게 부정적인 영향을 미치는지 조사할 수 있는 JS, HTML 및 CSS에 적용되는 사용 사례를 자유롭게 게시하십시오.

Milan Adamovsky

다음의 차이점 과 관련이 있을 수 있습니다.

• 텍스트 파일(각 줄은 줄 끝으로 끝나야 함)
• 바이너리 파일(말할 진정한 "줄"이 없으며 파일의 길이를 유지해야 함)

각 줄이 줄 끝에서 끝나는 경우 예를 들어 두 텍스트 파일을 연결하면 첫 번째 줄의 마지막 줄이 두 번째 줄의 첫 번째 줄로 실행되는 것을 방지할 수 있습니다.

또한 편집기는 로드 시 파일이 줄 끝에서 끝나는지 확인하고 로컬 옵션 'eol'에 저장하고 파일을 작성할 때 이를 사용할 수 있습니다.

몇 년 최종 EOL, "잊지"는 않았다 (2005) 많은 편집자 (ZDE, 이클립스, Scite를, ...) 백업 매우 평가되지 않았습니다 .
뿐만 아니라 최종 EOL을 '새 줄 시작'으로 잘못 해석하여 실제로는 이미 있는 것처럼 다른 줄을 표시하기 시작합니다.
이것은 위의 편집기 중 하나에서 여는 것과 비교하여 vim과 같이 잘 작동하는 텍스트 편집기를 사용하여 '적절한' 텍스트 파일을 사용했을 때 매우 뚜렷했습니다. 파일의 실제 마지막 줄 아래에 추가 줄을 표시했습니다. 다음과 같은 내용이 표시됩니다.

 1 first line 2 middle line 3 last line 4

VonC

일부 도구에서는 이를 예상합니다. 예를 들어 wc 는 다음을 기대합니다.

 $ echo -n "Line not ending in a new line" | wc -l 0 $ echo "Line ending with a new line" | wc -l 1

Flimm

기본적으로 최종 EOL EOF를 얻지 못하면 파일을 올바르게 처리하지 못하는 프로그램이 많이 있습니다.

GCC는 C 표준의 일부로 예상되기 때문에 이에 대해 경고합니다. (섹션 5.1.1.2 분명히)

"파일 끝에 줄 바꿈 없음" 컴파일러 경고

cgp

별도의 사용 사례: 텍스트 파일이 버전 제어되는 경우(이 경우 특히 git 아래에 있지만 다른 경우에도 적용됨). 파일 끝에 내용이 추가되면 이전에 마지막 줄이었던 줄이 개행 문자를 포함하도록 편집됩니다. 즉, 해당 줄이 마지막으로 편집된 시간을 찾기 위해 파일을 blame

Robin Whittleton

나는 몇 년 동안 이것을 스스로 궁금해했습니다. 그런데 오늘 좋은 이유를 찾았습니다.

모든 행에 레코드가 있는 파일을 상상해 보십시오(예: CSV 파일). 그리고 컴퓨터는 파일의 끝에 기록을 쓰고 있었습니다. 그런데 갑자기 무너졌습니다. 이런, 마지막 줄이 완성되었나요? (좋은 상황은 아님)

그러나 우리가 항상 마지막 라인을 종료한다면, 우리는 알게 될 것입니다(단순히 마지막 라인이 종료되었는지 확인하십시오). 그렇지 않으면 안전을 위해 매번 마지막 줄을 버려야 할 것입니다.

symbiont

이것은 간단한 터미널이 사용된 아주 초기부터 시작됩니다. 개행 문자는 전송된 데이터의 '플러시'를 트리거하는 데 사용되었습니다.

오늘날에는 개행 문자가 더 이상 필요하지 않습니다. 물론 줄 바꿈이 없으면 많은 앱에 여전히 문제가 있지만 해당 앱의 버그라고 생각합니다.

그러나 줄 바꿈이 필요한 텍스트 파일 형식이 있는 경우 간단한 데이터 확인을 매우 저렴하게 얻을 수 있습니다. 파일이 끝에 줄 바꿈이 없는 줄로 끝나는 경우 파일이 손상되었음을 알 수 있습니다. 각 라인에 하나의 추가 바이트만 있으면 CPU 시간이 거의 없고 높은 정확도로 깨진 파일을 감지할 수 있습니다.

Stefan

위의 실용적인 이유 외에도 Unix의 창시자(Thompson, Ritchie, et al.) 또는 Multics의 전임자가 줄 구분 기호 대신 줄 종결자를 사용해야 하는 이론적 이유가 있음을 깨달았다고 해도 놀라지 않을 것입니다. 터미네이터를 사용하면 가능한 모든 줄 파일을 인코딩할 수 있습니다. 줄 구분 기호를 사용하면 줄이 없는 파일과 빈 줄 하나가 포함된 파일 간에 차이가 없습니다. 둘 다 0 문자를 포함하는 파일로 인코딩됩니다.

따라서 이유는 다음과 같습니다.

1. 그것이 POSIX가 정의하는 방식이기 때문입니다.
2. 일부 도구는 그것을 기대하거나 그것 없이 "오작동"하기 때문입니다. 예를 들어, wc -l 은 줄 바꿈으로 끝나지 않으면 마지막 "줄"을 계산하지 않습니다.
3. 간단하고 편리하기 때문입니다. Unix에서 cat 은 복잡하지 않고 작동합니다. 해석할 필요 없이 각 파일의 바이트만 복사합니다. cat 해당하는 DOS가 없다고 생각합니다. copy a+bc 사용하면 a b 의 첫 번째 줄과 병합하게 됩니다.
4. 0줄의 파일(또는 스트림)이 1줄의 빈 파일과 구별될 수 있기 때문입니다.

jrw32982

끝에 줄 바꿈이 없는 파일에 대한 실용적인 프로그래밍 문제도 있습니다. read Bash 내장(다른 read 구현에 대해서는 잘 모릅니다)이 예상대로 작동하지 않습니다.

 printf $'foo\nbar' | while read line do echo $line done

이것은 foo 만 인쇄합니다! 그 이유는 read 가 마지막 줄을 만나면 내용을 $line 쓰지만 EOF에 도달했기 때문에 종료 코드 1을 반환하기 때문입니다. 이것은 while echo $line 부분에 도달하지 않습니다. 이 상황을 처리하려면 다음을 수행해야 합니다.

 while read line || [ -n "${line-}" ] do echo $line done < <(printf $'foo\nbar')

즉, 파일 끝에 비어 있지 않은 행으로 인해 read 실패한 경우 echo 당연히, 이 경우 입력에 없는 하나의 추가 개행이 출력에 있을 것입니다.

l0b0

아마도 단순히 일부 구문 분석 코드가 거기에 있을 것으로 예상했기 때문일 것입니다.

나는 그것을 "규칙"으로 간주할지 확신이 서지 않으며 확실히 내가 종교적으로 고수하는 것이 아닙니다. 가장 합리적인 코드는 텍스트(인코딩 포함)를 마지막 줄에 줄 바꿈 유무에 관계없이 줄 단위로(줄 끝의 모든 선택) 구문 분석하는 방법을 알고 있습니다.

실제로 - 새 줄로 끝나는 경우 EOL과 EOF 사이에 (이론적으로) 빈 마지막 줄이 있습니까? 고민해볼 1인...

Marc Gravell

(텍스트) 파일이 개행으로 끝나야 하는 이유는 무엇입니까?

다음과 같은 이유로 많은 사람들이 표현합니다.

1. 많은 프로그램이 제대로 작동하지 않거나 그렇지 않으면 실패합니다.

2. 파일을 잘 처리하는 프로그램에도 끝이 '\n' 가 없어 도구의 기능이 사용자의 기대를 충족하지 못할 수 있습니다. 이는 이 경우에 명확하지 않을 수 있습니다.

3. 프로그램 은 마지막 '\n' 거의 허용하지 않습니다(나는 모릅니다).

---

그러나 이것은 다음 질문을 요구합니다.

줄 바꿈이 없는 텍스트 파일에 대해 코드는 무엇을 해야 합니까?

1. 가장 중요한 것 - 텍스트 파일이 개행 문자로 끝나는 것으로 가정하는 코드를 작성하지 마십시오 . 파일이 형식을 준수한다고 가정하면 데이터 손상, 해커 공격 및 충돌이 발생합니다. 예시:

    // Bad code while (fgets(buf, sizeof buf, instream)) { // What happens if there is no \n, buf[] is truncated leading to who knows what buf[strlen(buf) - 1] = '\0'; // attempt to rid trailing \n ... }

2. 마지막 후행 '\n' 이 필요한 경우 사용자에게 해당 항목의 부재와 취한 조치를 알립니다. IOW, 파일 형식을 확인합니다. 참고: 여기에는 최대 줄 길이, 문자 인코딩 등에 대한 제한이 포함될 수 있습니다.

3. '\n' 처리를 명확하게 문서화하십시오.

4. 가능한 한 '\n' 끝이 없는 파일을 생성 하지 마십시오.

chux - Reinstate Monica

여기에서 매우 늦었지만 파일 처리에서 한 가지 버그에 직면했으며 파일이 빈 줄 바꿈으로 끝나지 않았기 때문에 발생했습니다. 우리는 텍스트 파일을 처리했다 sed 하고 sed 잘못된 JSON 구조를 일으키는 출력에서 마지막 줄을 생략하고 상태를 실패하는 과정의 나머지를 전송했다.

우리가 하고 있던 일은 다음과 같습니다.

하나의 샘플 파일이 있습니다. foo.txt 안에 일부 json 콘텐츠가 포함되어 있습니다.

 [{ someProp: value }, { someProp: value }] <-- No newline here

파일은 widows 시스템에서 생성되었으며 윈도우 스크립트는 PowerShell 명령을 사용하여 해당 파일을 처리하고 있었습니다. 문제 없다.

sed 명령을 사용하여 동일한 파일을 처리할 때 sed 's|value|newValue|g' foo.txt > foo.txt.tmp

새로 생성된 파일은

 [{ someProp: value }, { someProp: value

그리고 붐, 잘못된 JSON 때문에 나머지 프로세스가 실패했습니다.

따라서 항상 빈 줄 바꿈으로 파일을 끝내는 것이 좋습니다.

Arpit

나는 줄 바꿈 없이 파일을 구문 분석하는 것이 어려웠던 시절부터 규칙이 생겼다는 인상을 항상 받았습니다. 즉, 줄 끝이 EOL 문자 또는 EOF로 정의된 코드를 작성하게 됩니다. 줄이 EOL로 끝났다고 가정하는 것이 더 간단했습니다.

그러나 나는 규칙이 개행을 요구하는 C 컴파일러에서 파생되었다고 생각합니다. 그리고 "파일 끝에 줄 바꿈 없음" 컴파일러 경고에서 지적했듯이 #include는 줄 바꿈을 추가하지 않습니다.

he_the_great

왜 텍스트 파일은 개행으로 끝나야 합니까?

그것이 가장 현명한 선택이기 때문입니다.

다음 내용이 포함된 파일을 가져옵니다.

 one\n two\n three

여기서 \n 은 줄 바꿈 문자를 의미합니다. Windows에서는 \r\n 반환 문자 뒤에 줄 바꿈이 있습니다. 정말 멋지죠?

이 파일에는 몇 줄이 있습니까? Windows는 3, 우리는 3, POSIX(Linux)는 파일 끝에 \n

그럼에도 불구하고 마지막 줄은 무엇이라고 말하겠습니까? three 이 파일의 마지막 줄이라는 데 동의하는 사람이 있을 것 같지만 POSIX는 그것이 손상된 줄이라고 말합니다.

그리고 두 번째 줄은 무엇입니까? 오, 여기에 첫 번째 강력한 분리가 있습니다 .

• Windows는 파일이 "줄 바꿈으로 구분된 줄"(wth?)이기 때문에 two
• POSIX는 two\n 라고 말하며 이것이 진실하고 정직한 줄이라고 덧붙입니다.

그렇다면 Windows 선택의 결과는 무엇입니까? 단순한:

파일이 줄로 구성되어 있다고 말할 수 없습니다.

왜요? 이전 파일에서 마지막 줄을 가져와서 몇 번 복제해 보십시오... 무엇을 얻었습니까? 이것:

 one\n two\n threethreethreethree

대신 두 번째 줄과 세 번째 줄을 바꾸십시오. 그러면 다음과 같이 됩니다.

 one\n threetwo\n

그러므로

텍스트 파일은 한 줄로 시작하여 줄로 끝나는 \n

꽤 한 입입니다.

그리고 또 다른 이상한 결과를 원하십니까?

빈 파일(0비트)은 마술처럼 한 줄짜리 파일이라는 사실을 받아들여야 합니다.

정말 미친 짓이라고 생각하지 않습니까?

POSIX 선택의 결과는 무엇입니까?

맨 위에 있는 파일이 약간 손상되었으며 이를 처리하려면 해킹이 필요합니다.

진지하다

나는 앞의 텍스트에서 도발적입니다 \n 이 없는 텍스트 파일을 처리하면 임시 틱/핵으로 처리해야 하기 때문입니다. 문제가 있는 줄을 처리하는 분기가 불구가 된 줄만 처리하고 다른 모든 줄은 다른 분기를 사용하는 곳에서 작업을 수행 if / else 가 항상 필요합니다. 좀 인종차별적이죠?

나의 결론

저는 다음과 같은 이유로 라인의 POSIX 정의에 찬성합니다.

• 파일은 자연스럽게 일련의 행으로 간주됩니다.
• 파일의 위치에 따라 한 줄은 다른 것이 되어서는 안 됩니다.
• 빈 파일은 한 줄짜리 파일이 아닙니다.
• 코드를 해킹하도록 강요해서는 안 됩니다.

Enlico

파일이 여전히 다른 프로세스에 의해 생성되는 동안 파일이 처리되고 있다고 상상해 보십시오.

그것과 관련이 있지 않을까요? 파일을 처리할 준비가 되었음을 나타내는 플래그입니다.

Pippen_001

저는 개인적으로 소스 코드 파일의 끝에 새 줄을 넣는 것을 좋아합니다.

Linux 또는 해당 문제에 대한 모든 UNIX 시스템에서 기원했을 수 있습니다. 소스 코드 파일이 빈 줄 바꿈으로 끝나지 않았기 때문에 컴파일 오류(실수가 아니라면 gcc)가 있었던 걸로 기억합니다. 왜 이런 식으로 만들어졌는지 궁금증이 남습니다.

User

IMHO, 개인 스타일과 의견의 문제입니다.

옛날에는 그 개행문자를 넣지 않았습니다. 문자가 저장되었다는 것은 14.4K 모뎀을 통해 더 빠른 속도를 의미합니다.

나중에 shift+아래쪽 화살표를 사용하여 마지막 줄을 더 쉽게 선택할 수 있도록 줄 바꿈을 넣었습니다.

Torben Gundtofte-Bruun

출처 : http:www.stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline