2010-02-18 29 views
137

Một số công cụ kiểu mã đề xuất điều này và tôi nhớ thấy một số công cụ dòng lệnh unix cảnh báo về thiếu dòng trống.Tại sao đề xuất có dòng trống ở cuối tệp?

Lý do để có thêm dòng trống là gì?

+5

Một số công cụ không hoạt động nếu tập tin không kết thúc với một dòng mới. Điều đó khác với việc có một dòng trống ở cuối (sẽ là 2 dòng mới). –

+0

Trình soạn thảo văn bản Gedit và Nano (và được báo cáo là Vim) sẽ thêm một dòng trống vào bất kỳ tài liệu nào bạn lưu. –

+1

Bạn có nghĩa là dòng trống ('\ n \ n') hoặc dòng mới' \ n'? –

Trả lời

110

Nhiều công cụ cũ sẽ hoạt động sai nếu dòng cuối cùng của dữ liệu trong tệp văn bản không bị chấm dứt bằng kết hợp dòng mới hoặc dòng vận chuyển/dòng mới. Họ bỏ qua dòng đó vì nó được kết thúc với^Z (eof) thay thế.

+0

Cảm ơn bạn đã trả lời! Bất kỳ ví dụ về các công cụ phổ biến nào có thể thể hiện hành vi này? – cloudrave

+2

@NickM Hầu như tất cả các công cụ dòng lệnh POSIX/Unix nhập văn bản hoặc đọc một tệp văn bản giả định một dòng kết thúc ('\ n') ở cuối tệp. Một số trình soạn thảo văn bản, như Vim và một số trình biên dịch (đáng chú ý là C++ và Python) sẽ đưa ra các cảnh báo. (Trong trường hợp của C++, tiêu chuẩn đòi hỏi điều này một cách rõ ràng.) – greyfade

28

Ngoài thực tế là vị trí con trỏ đẹp hơn khi bạn di chuyển đến cuối tệp trong trình chỉnh sửa văn bản.

Có một dòng mới ở cuối tệp cung cấp một kiểm tra đơn giản rằng tệp chưa bị cắt bớt.

+151

Tệp có thể bị cắt bớt và bạn sẽ không bao giờ bị kn –

+1

Phần đầu tiên là chính xác, phần thứ hai là không. –

10

Dòng trống ở cuối tệp xuất hiện để đọc chuẩn từ luồng đầu vào sẽ biết khi nào chấm dứt đọc, thường trả về EOF để cho biết bạn đã đến cuối. Phần lớn các ngôn ngữ có thể xử lý điểm đánh dấu EOF. Chính vì lý do đó từ những ngày cũ, dưới DOS, điểm đánh dấu EOF là phím F6 hoặc Ctrl-Z, cho các hệ thống * nix, đó là Ctrl-D.

Hầu hết, nếu không phải tất cả, thực sự sẽ đọc ngay đến điểm đánh dấu EOF để chức năng đọc của thư viện thời gian chạy từ đầu vào sẽ biết khi nào nên dừng đọc thêm nữa. Khi bạn mở luồng cho chế độ Nối, nó sẽ xóa đánh dấu EOF và ghi qua nó, cho đến khi đóng được gọi một cách rõ ràng trong đó nó sẽ chèn điểm đánh dấu EOF vào thời điểm đó.

Công cụ cũ hơn mong đợi một dòng trống, theo sau là dấu EOF. Ngày nay, các công cụ có thể xử lý dòng trống và bỏ qua nó.

+5

^D không phải là "dấu đánh dấu EOF". Nhấn^D khiến vỏ đóng gần mặt ghi của đường ống mà nhóm tiến trình nền trước đang đọc, để đọc từ ống đó trả về EOF. Không có "điểm đánh dấu EOF". –

+0

@William Pursell Bạn nhầm lẫn bị nhầm lẫn * NIX và Windows. Windows/DOS cũ đã hoàn toàn sử dụng một dấu đánh dấu EOF (26, 0x1a) được nhúng thường ở phần cuối của hầu hết các tệp dưới dạng sự lưu trữ để tương thích với CP/M cũ (Ai đã sử dụng CP/M sau năm 1983?). "Fun" khác: '\ r \ n' thay vì' \ n', các cuộc gọi DOS sử dụng kết hợp ASCIIZ và ASCII $. Thậm chí tệ hơn, sau này Windows thường chèn một dấu thứ tự byte Unicode (BOM) vào đầu của hầu hết các tệp văn bản. Đáng yêu "độc đáo". – Barry

2

Một số ngôn ngữ xác định tệp đầu vào của họ theo dòng đầu vào, trong đó mỗi dòng đầu vào là một chuỗi các ký tự được kết thúc bằng một dấu xuống dòng. Nếu ngữ pháp của họ được xác định như vậy, thì dòng hợp lệ cuối cùng của tệp phải được kết thúc bằng một dấu xuống dòng.

7

Ngoài ra khi bạn sửa đổi tệp và chắp thêm một số mã ở cuối tệp - khác biệt (ít nhất là git diff trong tiêu chuẩn) sẽ cho thấy bạn đã thay đổi dòng cuối cùng, trong khi điều duy nhất bạn đã thực hiện - thêm biểu tượng dòng mới. Vì vậy, các báo cáo cvs trở nên kém thuận tiện hơn.

21

Nếu bạn cố ghép hai tệp văn bản lại với nhau, bạn sẽ hạnh phúc hơn nhiều nếu đầu tiên kết thúc bằng ký tự dòng mới.

Các vấn đề liên quan