unix

이 답변은 의견이 아닌 기술적 답변을 시도한 것입니다.

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

이로부터 우리는 잠재적으로 어떤 유형의 문제가 발생할 수 있는 유일한 시간 은 파일 의 줄 또는 파일 의 개념을 텍스트 파일 로서 텍스트 파일 ( 텍스트 파일 이 0으로 구성 되어 있다는 것)을 다룰 때 뿐이라는 것을 알 수 있습니다 또는 그 이상의 줄과 우리가 알고있는 줄은 <newline>으로 끝나야합니다).

적절한 사례 : wc -l filename.

에서 wc의 사용 설명서 우리는 읽기 :

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

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

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

결과적으로 EOF의 EOL이 UNIX OS에서 실행되는지 여부에 관계없이 EOF의 EOL이 애플리케이션 레벨에서 사실상 부정적인 영향을 미치지 않을 것이라고 확신 할 수 있습니다.

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

이 단계를 한 단계 더 나아가서 NodeJS에 관한 한 POSIX 표준을 준수 할 수 없다는 점은 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해야 할 일을합니다.

는 <newline>이 아니라 EOF까지 입력을 읽는 man것에 cat대해서만 언급합니다. 주의가 있는지 -n의 스위치는 cat또한 비 <개행> 종료 행 (또는 출력한다 불완전한 라인 A와) 라인 – 인을 카운트에서 시작하는 1 단계 (받는 항 man).

-n 1부터 시작하여 출력 라인의 번호를 지정합니다.

POSIX가 어떻게 라인을 정의하는지 이해 했으므로 ,이 동작은 모호하거나 실제로 비 호환이됩니다.

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

예를 들어, wc -l filename하나 를 사용하는 대신 할 수 awk '{x++}END{ print x}' filename있고 작업의 성공이 우리가 작성하지 않은 처리하려는 파일 (예 : 축소 된 JS와 같은 타사 라이브러리)에 의해 위험에 처하지 않음을 확신 curl하십시오. 의도는 진정으로 줄 을 세는 것이 었습니다 POSIX 호환 의미에서 .

결론

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

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

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

답변

1 first line
2 middle line
3 last line
4

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