파일 끝에 줄 바꿈이 없습니다.

파일 끝에 줄 바꿈이 없습니다.

---

를 수행 할 때 git diff그것은 말한다 "파일의 마지막에 개행 문자가" .

좋아, 파일 끝에 줄 바꿈이 없습니다. 큰 문제는 무엇입니까?

이 메시지의 의미는 무엇이며 우리에게 무엇을 말하려고합니까?

---

'\n'파일 끝에 줄 바꿈 (보통 CR 또는 CRLF) 이 없음을 나타냅니다 .

즉, 간단히 말하면 파일의 마지막 바이트 (또는 Windows의 경우 바이트)는 줄 바꿈이 아닙니다.

그렇지 않으면 마지막에 줄 바꿈이있는 파일과 그렇지 않은 파일의 차이를 구분할 방법이 없기 때문에 메시지가 표시됩니다. Diff는 어쨌든 개행을 출력해야합니다. 그렇지 않으면 결과를 자동으로 읽거나 처리하기가 더 어려워집니다.

파일 형식에서 허용되는 경우 항상 줄 바꿈을 마지막 문자로 두는 것이 좋은 스타일입니다. 또한, 예를 들어 C 및 C ++ 헤더 파일의 경우 언어 표준에 필요합니다.

---

나쁜 스타일 일뿐 만 아니라 파일에서 다른 도구를 사용할 때 예기치 않은 동작이 발생할 수 있습니다.

여기 있습니다 test.txt:

first line
second line

마지막 줄에는 줄 바꿈 문자가 없습니다. 파일에 몇 줄이 있는지 봅시다 :

$ wc -l test.txt
1 test.txt

어쩌면 그것이 원하는 것일 수도 있지만 대부분의 경우 파일에 2 줄이있을 것으로 예상합니다.

또한 파일을 결합하려는 경우 예상대로 작동하지 않을 수 있습니다.

$ cat test.txt test.txt
first line
second linefirst line
second line

마지막으로 새 줄을 추가하면 diff가 약간 더 시끄 럽습니다. 세 번째 줄을 추가 한 경우 새 줄뿐만 아니라 두 번째 줄에 대한 편집 내용이 표시됩니다.

---

유일한 이유는 유닉스가 역사적으로 개행으로 끝나는 사람이 읽을 수있는 모든 텍스트 파일의 규칙을 가지고 있기 때문입니다. 당시에는 텍스트 파일을 표시하거나 결합 할 때 추가 처리를 피하고 텍스트 파일을 다른 종류의 데이터 (예 : 사람이 읽을 수없는 원시 이진 데이터)가 포함 된 파일과 다르게 처리하지 않았습니다.

이러한 규칙으로 인해 당시의 많은 도구는 텍스트 편집기, diffing 도구 및 기타 텍스트 처리 도구를 포함하여 줄 바꿈 줄을 기대합니다. Mac OS X은 BSD Unix를 기반으로 구축되었으며 Linux는 Unix와 호환되도록 개발되었으므로 두 운영 체제 모두 동일한 규칙, 동작 및 도구를 상속받습니다.

Windows는 Unix와 호환되도록 개발되지 않았으므로 동일한 규칙이 없으며 대부분의 Windows 소프트웨어는 줄 바꿈없이 잘 처리됩니다.

그러나 Git이 먼저 Linux 용으로 개발되었고 Linux, Mac OS X, FreeBSD 등과 같은 Unix 호환 시스템에 많은 오픈 소스 소프트웨어가 구축되었으므로 대부분의 오픈 소스 커뮤니티 및 해당 도구 (프로그래밍 언어 포함)는 계속됩니다 이러한 규칙을 따르십시오.

1971 년에 의미가있는 기술적 인 이유가 있지만, 현재는 기존 도구와의 호환성을 유지하는 것이 관례입니다.

---

파일 끝에 줄 바꿈이 없음을 나타냅니다. 명령 행에서 diff를 볼 때 존재하지 않는다는 것을 분명히하기위한 메시지 일뿐입니다.

---

기존 파일의 끝에 아직 끝에 없는 새 텍스트 줄 을 추가 newline character하면 diff는 개념적으로 그렇지 않더라도 이전의 마지막 줄이 수정 된 것으로 표시합니다.

이것이 newline character끝에 추가해야하는 최소한 하나의 이유 입니다.

예

파일은 다음을 포함합니다 :

A() {
    // do something
}

16 진 덤프 :

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d              something.}

당신은 지금 그것을 편집

A() {
    // do something
}
// Useful comment

16 진 덤프 :

00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20  A() {.    // do 
00000010: 736f 6d65 7468 696e 670a 7d0a 2f2f 2055  something.}.// U
00000020: 7365 6675 6c20 636f 6d6d 656e 742e 0a    seful comment..

git diff는 다음을 보여줍니다.

-}
\ No newline at end of file
+}
+// Useful comment.

즉, 개념적으로 발생하는 것보다 더 큰 차이를 보여줍니다. 행을 삭제하고 행 }을 추가 했음을 나타냅니다 }\n. 이것은 실제로 일어난 일이지만 개념적으로 일어난 일은 아니므로 혼동 될 수 있습니다.

---

이전 응답에서 볼 수없는 것이 있습니다. 줄 끝이 없다는 경고는 파일의 일부가 잘 렸을 때 경고가 될 수 있습니다. 데이터가 누락 된 증상 일 수 있습니다.

---

이 규칙이 실행 된 이유는 UNIX 계열 운영 체제에서 줄 바꾸기 문자가 줄 종결 자 및 / 또는 메시지 경계로 처리되기 때문입니다 (프로세스 간 연결, 줄 버퍼링 등).

예를 들어, 개행 문자 만있는 파일은 하나의 빈 행으로 취급됩니다. 반대로, 길이가 0 바이트 인 파일은 실제로는 0 행의 빈 파일입니다. 이것은 wc -l명령 에 따라 확인할 수 있습니다 .

\n문자가 단순히 행 종결자가 아닌 행 구분자 인 경우 빈 텍스트 파일과 하나의 빈 행이있는 텍스트 파일을 구분하는 다른 방법이 없기 때문에이 동작은 합리적 입니다. 따라서 유효한 텍스트 파일은 항상 개행 문자로 끝나야합니다. 텍스트 파일이 비어있는 경우 (행 없음)는 예외입니다.

---

핵심 문제는 줄을 정의하는 것과 줄 끝 문자 시퀀스가 ​​줄의 일부인지 여부입니다. UNIX 기반 편집기 (예 : VIM) 또는 도구 (예 : Git)는 EOL 문자 시퀀스를 줄 종결 자로 사용하므로 줄의 일부입니다. C와 Pascal에서 세미콜론 (;)을 사용하는 것과 비슷합니다. C 세미콜론에서는 명령문이 종료되고 파스칼에서는 명령문이 분리됩니다.

---

소스 파일은 도구 (C, C ++ : 헤더 파일, Javascript : 번 들러)로 연결되는 경우가 많습니다. 줄 바꿈 문자를 생략하면 불쾌한 버그가 발생할 수 있습니다 (한 소스의 마지막 줄이 다음 소스 파일의 첫 줄과 연결됨). 바라건대 모든 소스 코드 연결 도구는 연결 된 파일 사이에 줄 바꿈을 삽입하지만 항상 그렇지는 않습니다.

문제의 요점은 대부분의 언어에서 줄 바꿈이 의미 론적 의미를 가지며 파일 끝은 줄 바꿈 문자의 언어 정의 대안이 아닙니다. 따라서 마지막 문장을 포함하여 줄 바꿈 문자로 모든 문장 / 표현을 종료해야합니다.

---

줄 끝은 변경하지 않고 더티 파일을 자동으로 수정하기 때문에 실제로 문제가 발생합니다. 해결 방법은이 게시물을 참조하십시오.

LF를 CRLF로 대체하는 git

---

원본 파일에 줄 바꿈 문자가 없었을 것입니다.

그러나 리눅스에서 gedit 와 같은 일부 편집기 는 파일 끝에 줄 바꿈을 자동으로 추가합니다. 이런 종류의 편집기를 사용하는 동안이 메시지를 제거 할 수 없습니다.

이 문제를 극복하려고 시도한 것은 Visual Studio 코드 편집기로 파일을 여는 것입니다.

이 편집기는 마지막 줄을 명확하게 표시하며 원하는대로 줄을 삭제할 수 있습니다.

---

가치있는 일을 위해 Mac에서 IntelliJ 프로젝트를 만든 다음 프로젝트를 Windows 시스템으로 옮길 때이 문제가 발생했습니다. 모든 파일을 수동으로 열고 IntelliJ 창의 오른쪽 하단에서 인코딩 설정을 변경해야했습니다. 아마도이 질문을 읽은 사람이 저에게 몇 시간의 노동력을 절약 할 수 있다면 아마도 대부분 일어나지 않을 것입니다 ...

참고 URL : https://stackoverflow.com/questions/5813311/no-newline-at-end-of-file