답변:
'\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 년에 의미가있는 기술적 인 이유가 있지만이 시대에는 기존 도구와의 호환성을 유지하는 것이 관례입니다.
기존 파일의 끝에 아직 끝에 없는 새 텍스트 줄 을 추가 newline character하면 diff는 개념적으로 그렇지 않더라도 이전 마지막 줄이 수정 된 것으로 표시합니다.
이것이 newline character끝에 추가해야하는 최소한 하나의 이유 입니다.
파일은 다음을 포함합니다 :
A() {
// do something
}
Hexdump에서는 :
00000000: 4128 2920 7b0a 2020 2020 2f2f 2064 6f20 A() {. // do
00000010: 736f 6d65 7468 696e 670a 7d something.}
당신은 지금 그것을 편집
A() {
// do something
}
// Useful comment
Hexdump에서는 :
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문자가 단순히 줄 종결자가 아닌 줄 구분자 인 경우 빈 텍스트 파일과 빈 줄이 하나있는 텍스트 파일을 구분하는 다른 방법이 없기 때문에이 동작은 합리적 입니다. 따라서 유효한 텍스트 파일은 항상 개행 문자로 끝나야합니다. 텍스트 파일이 비어있는 경우 (행 없음)는 예외입니다.
줄 끝은 변경하지 않고 더티 파일을 자동으로 수정하기 때문에 실제로 문제가 발생합니다. 해결 방법은이 게시물을 참조하십시오.
소스 파일은 도구 (C, C ++ : 헤더 파일, Javascript : 번 들러)로 연결되는 경우가 많습니다. 줄 바꿈 문자를 생략하면 불쾌한 버그가 발생할 수 있습니다 (한 소스의 마지막 줄이 다음 소스 파일의 첫 줄과 연결됨). 바라건대 모든 소스 코드 연결 도구는 연결 된 파일 사이에 줄 바꿈을 삽입하지만 항상 그렇지는 않습니다.
문제의 핵심은 대부분의 언어에서 줄 바꿈이 의미 론적 의미를 가지며 파일 끝은 줄 바꿈 문자의 언어 정의 대안이 아닙니다. 따라서 마지막 문장을 포함하여 줄 바꿈 문자로 모든 문장 / 표현을 종료해야합니다.
//코드의 중간에 스타일의 코멘트를.
원본 파일에 줄 바꿈 문자가 없었을 것입니다.
그러나 리눅스에서 gedit 와 같은 일부 편집기 는 파일 끝에 줄 바꿈을 자동으로 추가합니다. 이런 종류의 편집기를 사용하는 동안이 메시지를 제거 할 수 없습니다.
이 문제를 극복하려고 시도한 것은 Visual Studio 코드 편집기로 파일을 여는 것입니다.
이 편집기는 마지막 줄을 명확하게 표시하며 원하는대로 줄을 삭제할 수 있습니다.