일부 컴파일러 (특히 C 또는 C ++ 컴파일러)는 다음에 대한 경고를 제공합니다.
No new line at end of file
나는 이것이 C 프로그래머 전용 문제라고 생각했지만 github는 커밋 뷰에 메시지를 표시합니다.
\ No newline at end of file
PHP 파일의 경우.
이 스레드에 설명 된 전 처리기 문제를 이해합니다 .하지만 이것이 PHP와 어떤 관련이 있습니까? 같은 include()것 입니까 아니면 \r\nvs \n주제 와 관련이 있습니까?
파일 끝에 새 줄이 있다는 점은 무엇입니까?
파일 끝에 새 줄을 추가하는 것이 아니라 거기에 있어야하는 줄 바꿈을 제거하지 않는 것입니다.
유닉스 아래 의 텍스트 파일 은 줄 바꿈 문자 ( )로 끝나는 일련의 줄로 구성됩니다 . 따라서 비어 있지 않고 줄 바꿈으로 끝나지 않는 파일은 텍스트 파일이 아닙니다.\n
텍스트 파일에서 작동하도록되어있는 유틸리티는 줄 바꿈으로 끝나지 않는 파일을 잘 처리하지 못할 수 있습니다. 예를 들어, 역사적인 유닉스 유틸리티는 마지막 줄 바꿈 뒤의 텍스트를 무시할 수 있습니다. GNU 유틸리티는 텍스트가 아닌 파일에 대해 적절하게 작동하는 정책을 가지고 있으며 대부분의 다른 최신 유틸리티도 마찬가지이지만 최종 줄 바꿈 ¹이 누락 된 파일에서는 여전히 이상한 동작이 발생할 수 있습니다.
GNU diff를 사용하면 비교되는 파일 중 하나가 줄 바꿈으로 끝나고 다른 파일은 끝나지 않으면 그 사실을주의해야합니다. diff는 라인 지향적이기 때문에 파일 중 하나에 대해 개행을 저장하여이를 나타낼 수는 없지만 다른 파일에는 개행을 저장하지 않습니다. 개행은 diff 파일의 각 행 이 시작되고 끝나는 위치를 표시하는 데 필요합니다 . 따라서 diff는이 특수 텍스트 \ No newline at end of file를 사용 하여 줄 바꿈으로 끝나지 않은 파일과 그렇지 않은 파일을 구별합니다.
그런데 C 컨텍스트에서 소스 파일은 유사하게 일련의 행으로 구성됩니다. 보다 정확하게는 번역 단위는 일련의 줄로 정의 된 구현에서 볼 수 있으며 각 줄은 줄 바꿈 문자 ( n1256 §5.1.1.1)로 끝나야합니다. 유닉스 시스템에서는 매핑이 간단합니다. DOS와 Windows에서 각 CR LF 시퀀스 ( \r\n)는 줄 바꿈으로 매핑됩니다 ( \n; 이것은 이러한 OS에서 텍스트로 열린 파일을 읽을 때 항상 발생합니다). 개행 문자가없는 대신 고정 또는 가변 크기의 레코드가있는 몇 가지 OS가 있습니다. 이러한 시스템에서 파일에서 C 소스로의 매핑은\n각 기록의 끝에. 이것은 유닉스와 직접적인 관련이 없지만 마지막 줄 바꿈이 누락 된 C 소스 파일을 레코드 기반 텍스트 파일이있는 시스템에 복사 한 다음 다시 복사하면 불완전한 상태가됩니다. 초기 변환에서 잘린 마지막 줄 또는 역변환 중에 추가 된 줄 바꿈.
¹ 예 : GNU 정렬의 출력은 항상 개행으로 끝납니다. 따라서 파일 foo에 마지막 줄 바꿈이 누락 된 sort foo | wc -c경우 cat foo | wc -c.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다