Câu trả lời này là một nỗ lực tại một câu trả lời kỹ thuật hơn là ý kiến.
Nếu chúng tôi muốn trở thành người theo chủ nghĩa POSIX, chúng tôi xác định một dòng là:
Một chuỗi gồm 0 hoặc nhiều ký tự không phải <dòng mới> cộng với ký tự <dòng mới> kết thúc.
Nguồn: https://pub.opengroup.org/onlinepub/9699919799/basingefs/V1_chap03.html#tag_03_206
Một dòng không đầy đủ như:
Một chuỗi gồm một hoặc nhiều ký tự không phải <dòng mới> ở cuối tệp.
Nguồn: https://pub.opengroup.org/onlinepub/9699919799/basingefs/V1_chap03.html#tag_03_195
Một tệp văn bản như:
Một tệp chứa các ký tự được tổ chức thành không hoặc nhiều dòng. Các dòng không chứa các ký tự NUL và không có ký tự nào có thể vượt quá độ dài {LINE_MAX}, bao gồm cả ký tự <newline>. Mặc dù POSIX.1-2008 không phân biệt giữa tệp văn bản và tệp nhị phân (xem tiêu chuẩn ISO C), nhiều tiện ích chỉ tạo ra đầu ra có thể dự đoán hoặc có ý nghĩa khi hoạt động trên tệp văn bản. Các tiện ích tiêu chuẩn có các hạn chế như vậy luôn chỉ định "tệp văn bản" trong phần STDIN hoặc INPUT PHIM.
Nguồn: https://pub.opengroup.org/onlinepub/9699919799/basingefs/V1_chap03.html#tag_03_397
Một chuỗi như:
Một chuỗi các byte liền kề được kết thúc bởi và bao gồm byte null đầu tiên.
Nguồn: https://pub.opengroup.org/onlinepub/9699919799/basingefs/V1_chap03.html#tag_03_394
Từ đó, chúng ta có thể rút ra rằng lần duy nhất chúng ta có khả năng gặp phải bất kỳ loại sự cố nào là nếu chúng ta xử lý khái niệm về một dòng của tệp hoặc tệp dưới dạng tệp văn bản (vì tệp văn bản là một tổ chức bằng không hoặc nhiều dòng hơn và một dòng chúng tôi biết phải chấm dứt bằng <dòng mới>).
Trường hợp tại điểm : wc -l filename.
Từ wchướng dẫn của chúng tôi, chúng tôi đọc:
Một dòng được định nghĩa là một chuỗi các ký tự được phân tách bằng ký tự <newline>.
Ý nghĩa của các tệp JavaScript, HTML và CSS là chúng là các tệp văn bản là gì?
Trong các trình duyệt, IDE hiện đại và các ứng dụng ngoại vi khác, không có vấn đề gì khi bỏ qua EOL tại EOF. Các ứng dụng sẽ phân tích các tập tin đúng cách. Do đó, không phải tất cả các Hệ điều hành đều tuân thủ tiêu chuẩn POSIX, do đó, sẽ không thực tế đối với các công cụ không phải hệ điều hành (ví dụ: trình duyệt) để xử lý các tệp theo tiêu chuẩn POSIX (hoặc bất kỳ tiêu chuẩn cấp hệ điều hành nào).
Do đó, chúng ta có thể tương đối tin tưởng rằng EOL ở EOF sẽ hầu như không có tác động tiêu cực ở cấp ứng dụng - bất kể nó có chạy trên HĐH UNIX hay không.
Tại thời điểm này, chúng tôi có thể tự tin nói rằng bỏ qua EOL tại EOF là an toàn khi giao dịch với JS, HTML, CSS ở phía máy khách. Trên thực tế, chúng tôi có thể tuyên bố rằng việc thu nhỏ bất kỳ một trong các tệp này, không chứa <newline> là an toàn.
Chúng ta có thể tiến thêm một bước này và nói rằng theo như NodeJS có liên quan thì nó cũng không thể tuân thủ tiêu chuẩn POSIX vì nó có thể chạy trong môi trường không tuân thủ POSIX.
Chúng ta còn lại gì sau đó? Công cụ cấp hệ thống.
Điều này có nghĩa là các vấn đề duy nhất có thể phát sinh là với các công cụ nỗ lực tuân thủ chức năng của chúng theo ngữ nghĩa của POSIX (ví dụ: định nghĩa của một dòng như trong hình wc).
Mặc dù vậy, không phải tất cả các shell sẽ tự động tuân thủ POSIX. Bash chẳng hạn không mặc định cho hành vi POSIX. Có một công tắc để kích hoạt nó : POSIXLY_CORRECT.
Thực phẩm cho suy nghĩ về giá trị của EOL là <newline>: https://www.rfc-editor.org/old/EOLstory.txt
Tiếp tục theo dõi công cụ, cho tất cả các ý định và mục đích thực tế, hãy xem xét điều này:
Hãy làm việc với một tệp không có EOL. Khi viết, tệp trong ví dụ này là một JavaScript được rút gọn không có 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
Lưu ý catkích thước tập tin chính xác là tổng của các phần riêng lẻ của nó. Nếu việc ghép các tệp JavaScript là mối quan tâm đối với các tệp JS, thì mối quan tâm thích hợp hơn sẽ là bắt đầu mỗi tệp JavaScript bằng dấu chấm phẩy.
Như một người khác đã đề cập trong chủ đề này: nếu bạn muốn cathai tệp có đầu ra chỉ là một dòng thay vì hai thì sao? Nói cách khác, catlàm những gì nó phải làm.
Các mancác catchỉ đề cập đến việc đọc đầu vào lên đến EOF, không <xuống dòng>. Lưu ý rằng công -ntắc của catcũng sẽ in ra một dòng kết thúc không phải là <newline> (hoặc dòng không đầy đủ ) dưới dạng một dòng - vì số đếm bắt đầu từ 1 (theo man.)
-n Đánh số các dòng đầu ra, bắt đầu từ 1.
Bây giờ chúng tôi hiểu cách POSIX định nghĩa một dòng , hành vi này trở nên mơ hồ hoặc thực sự không tuân thủ.
Hiểu mục đích và sự tuân thủ của một công cụ nhất định sẽ giúp xác định mức độ quan trọng của việc kết thúc các tệp bằng EOL. Trong C, C ++, Java (JAR), v.v ... một số tiêu chuẩn sẽ đưa ra một dòng mới về tính hợp lệ - không có tiêu chuẩn nào như vậy tồn tại đối với JS, HTML, CSS.
Ví dụ: thay vì sử dụng wc -l filenamemột cách có thể làm awk '{x++}END{ print x}' filenamevà hãy yên tâm rằng thành công của nhiệm vụ không bị nguy hiểm bởi một tệp mà chúng tôi có thể muốn xử lý mà chúng tôi đã không viết (ví dụ: thư viện bên thứ ba như JS đã rút gọn chúng tôi curld) - trừ khi chúng tôi ý định thực sự là đếm các dòng theo nghĩa tuân thủ POSIX.
Phần kết luận
Sẽ có rất ít trường hợp sử dụng thực tế trong đó bỏ qua EOL tại EOF đối với các tệp văn bản nhất định như JS, HTML và CSS sẽ có tác động tiêu cực - nếu có. Nếu chúng tôi dựa vào <newline>, chúng tôi sẽ hạn chế độ tin cậy của công cụ của chúng tôi đối với các tệp mà chúng tôi tạo ra và tự mở ra các lỗi tiềm ẩn do các tệp của bên thứ ba giới thiệu.
Đạo đức của câu chuyện: Kỹ sư công cụ không có điểm yếu là dựa vào EOL tại EOF.
Vui lòng gửi các trường hợp sử dụng khi chúng áp dụng cho JS, HTML và CSS nơi chúng tôi có thể kiểm tra việc bỏ qua EOL có ảnh hưởng xấu như thế nào.