Ця відповідь є спробою технічної відповіді, а не думкою.
Якщо ми хочемо бути пустиками POSIX, ми визначаємо рядок як:
Послідовність нульових або більше символів, що не належать <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
Текстовий файл як:
Файл, який містить символи, впорядковані в нуль або більше рядків. Рядки не містять символів NUL і жодна довжина не може перевищувати {LINE_MAX} байт, включаючи символ <newline>. Хоча POSIX.1-2008 не розрізняє текстові файли та бінарні файли (див. Стандарт ISO C), багато утиліт виробляють передбачуваний або змістовний вихід під час роботи з текстовими файлами. Стандартні утиліти, які мають такі обмеження, завжди вказують "текстові файли" у своїх розділах STDIN або INPUT FILES.
Джерело: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397
Рядок як:
Послідовна послідовність байтів, що закінчується і включає перший нульовий байт.
Джерело: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_396
Виходячи з цього , то ми можемо отримати , що єдиний раз , коли ми будемо потенційно зіткнутися будь-який тип питань , які , якщо ми маємо справу з поняттям лінії файлу або файлу в вигляді текстового файлу (будучи , що текстовий файл є організацією нуля або більше рядків, а лінія, яку ми знаємо, повинна закінчуватися <newline>).
Справа в точці: wc -l filename.
З wcпосібника ми читаємо:
Рядок визначається як рядок символів, обмежених символом <newline>.
Які наслідки стосуються файлів JavaScript, HTML та CSS, оскільки це текстові файли?
У веб-переглядачах, сучасних IDE та інших додаткових програмах немає проблем із пропусканням EOL на EOF. Програми будуть правильно розбирати файли. Тому, оскільки не всі Операційні системи відповідають стандарту POSIX, тому для інструментів, що не входять в ОС (наприклад, браузери), було б недоцільно обробляти файли відповідно до стандарту POSIX (або будь-якого стандарту на рівні ОС).
Як результат, ми можемо бути відносно впевненими, що EOL на EOF практично не матиме негативного впливу на рівні програми - незалежно від того, чи працює він на ОС UNIX.
На даний момент можна з упевненістю сказати, що пропуск EOL на EOF безпечний при роботі з JS, HTML, CSS на стороні клієнта. Власне, ми можемо стверджувати, що мінімізація будь-якого з цих файлів, що не містить <newline>, є безпечною.
Ми можемо зробити цей крок далі і сказати, що що стосується NodeJS, то він також не може дотримуватися стандарту POSIX, оскільки він може працювати в середовищах, не сумісних з POSIX.
Що ми залишилися тоді? Інструменти системного рівня.
Це означає, що єдині проблеми, які можуть виникнути, - це інструменти, які докладають зусиль, щоб дотримувати свою функціональність до семантики POSIX (наприклад, визначення рядка, як показано на wc).
Тим не менш, не всі оболонки автоматично дотримуються POSIX. Наприклад, Bash не є типовим для поведінки POSIX. Існує перемикач , щоб включити його: POSIXLY_CORRECT.
Їжа для роздумів про значення EOL, що є <newline>: https://www.rfc-editor.org/old/EOLstory.txt
Залишаючись на інструментальній доріжці, для всіх практичних намірів і цілей розглянемо наступне:
Давайте попрацюємо з файлом, який не має EOL. На цей час написання файлу в цьому прикладі є мінімізованим JavaScript без відсутності EOL.
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З catлише згадує читання вхідних даних до EOF, а не «рядки». Зауважте, що -nперемикач catтакож буде виводити не <newline> завершений рядок (або неповний рядок ) як рядок - оскільки кількість починається з 1 (відповідно до man.)
-n Пронумеруйте вихідні рядки, починаючи з 1.
Тепер, коли ми розуміємо, як POSIX визначає лінію , така поведінка стає неоднозначною або насправді невідповідною.
Розуміння мети та відповідності даного інструменту допоможе визначити, наскільки важливо закінчувати файли EOL. У C, C ++, Java (JAR) тощо, деякі стандарти будуть диктувати нову строку дійсності - такого стандарту не існує для JS, HTML, CSS.
Наприклад, замість того, щоб використовувати wc -l filenameце можна було awk '{x++}END{ print x}' filename, і будьте впевнені, що успіх завдання не загрожує файлу, який ми, можливо, захочемо обробити, який ми не написали (наприклад, стороння бібліотека, така як мінімізований JS, який ми curld) - якщо тільки наша Насправді було по-справжньому рахувати рядки в сумісному сенсі POSIX.
Висновок
Буде дуже мало випадків використання в реальному житті, коли пропуск EOL на EOF для певних текстових файлів, таких як JS, HTML та CSS, матиме негативний вплив - якщо він взагалі є. Якщо ми покладаємось на те, що <newline> присутній, ми обмежуємо надійність нашого інструментарію лише тими файлами, які ми автором, і відкриваємо себе до можливих помилок, введених сторонніми файлами.
Мораль історії: Інженерний інструмент, який не має слабкої сили покладатися на EOL на EOF.
Не соромтеся розміщувати випадки використання, оскільки вони застосовуються до JS, HTML та CSS, де ми можемо вивчити, як пропуск EOL має негативний вплив.