Các báo cáo tiến độ / thông tin đăng nhập thuộc về stderr hoặc stdout?

Có một POSIX, GNU hoặc hướng dẫn chính thức nào về nơi báo cáo tiến trình và thông tin đăng nhập (những thứ như "Làm foo; foo xong") nên được in không? Cá nhân, tôi có xu hướng viết chúng vào thiết bị xuất chuẩn để tôi có thể chuyển hướng thiết bị xuất chuẩn và chỉ nhận đầu ra thực tế của chương trình. Gần đây tôi đã nói rằng đây không phải là thông lệ tốt vì các báo cáo tiến độ không thực sự có lỗi và chỉ nên in thông báo lỗi cho thiết bị lỗi chuẩn.

Cả hai vị trí đều có ý nghĩa, và tất nhiên bạn có thể chọn cái này hay cái kia tùy thuộc vào chi tiết của những gì bạn đang làm, nhưng tôi muốn biết liệu có một tiêu chuẩn thường được chấp nhận cho việc này không. Tôi chưa thể tìm thấy bất kỳ quy tắc cụ thể nào trong POSIX, các tiêu chuẩn mã hóa GNU hoặc bất kỳ danh sách thực tiễn tốt nhất nào được chấp nhận rộng rãi như vậy.

Chúng tôi có một vài câu hỏi tương tự, nhưng chúng không giải quyết được vấn đề chính xác này:

• Khi nào nên sử dụng chuyển hướng đến thiết bị xuất chuẩn trong tập lệnh shell : Câu trả lời được chấp nhận cho thấy những gì tôi có xu hướng làm, giữ đầu ra cuối cùng của chương trình trên thiết bị xuất chuẩn và bất cứ điều gì khác cho thiết bị xuất chuẩn. Tuy nhiên, điều này chỉ được trình bày dưới dạng ý kiến ​​của người dùng, mặc dù được hỗ trợ bởi các đối số.

• Thông điệp sử dụng nên đi đến thiết bị xuất chuẩn hoặc thiết bị xuất chuẩn? : Điều này là cụ thể để giúp thông báo nhưng trích dẫn tiêu chuẩn mã hóa GNU. Đây là loại điều tôi đang tìm kiếm, chỉ không bị hạn chế để chỉ giúp đỡ tin nhắn.

Vì vậy, có bất kỳ quy tắc chính thức nào về nơi báo cáo tiến độ và thông báo thông tin khác (không phải là một phần của đầu ra thực tế của chương trình) nên được in không?

Posix định nghĩa các luồng tiêu chuẩn, do đó :

Khi khởi động chương trình, ba luồng phải được xác định trước và không cần phải mở một cách rõ ràng: đầu vào tiêu chuẩn (để đọc đầu vào thông thường), đầu ra tiêu chuẩn (để ghi đầu ra thông thường) và lỗi tiêu chuẩn (để ghi đầu ra chẩn đoán). Khi mở, luồng lỗi tiêu chuẩn không được đệm hoàn toàn; các luồng đầu vào tiêu chuẩn và đầu ra tiêu chuẩn được đệm hoàn toàn khi và chỉ khi luồng có thể được xác định không tham chiếu đến một thiết bị tương tác.

Các thư viện GNU C mô tả các dòng tiêu chuẩn tương tự:

Biến: FILE * stdout
Luồng đầu ra tiêu chuẩn, được sử dụng cho đầu ra bình thường từ chương trình.

Biến: FILE * stderr
Luồng lỗi tiêu chuẩn, được sử dụng cho các thông báo lỗi và chẩn đoán do chương trình ban hành.

Do đó, các định nghĩa tiêu chuẩn có rất ít hướng dẫn cho việc sử dụng luồng ngoài đầu ra thông thường / đầu ra bình thường và đầu ra chẩn đoán / lỗi thông thường. Và trong thực tế, thông thường để chuyển hướng một hoặc cả hai luồng này sang tệp và đường ống, trong đó các chỉ số tiến trình sẽ là một vấn đề . Một số hệ thống thậm chí giám sát stderr đầu ra và coi đó là dấu hiệu của sự cố. Do đó, thông tin hoàn toàn phụ trợ là vấn đề trên cả hai luồng.

Thay vì gửi các chỉ báo tiến trình vô điều kiện đến một luồng tiêu chuẩn, điều quan trọng là phải nhận ra rằng đầu ra tiến độ chỉ phù hợp với các luồng tương tác . Với ý nghĩ đó, tôi khuyên bạn chỉ nên viết bộ đếm tiến trình sau khi kiểm tra xem luồng có tương tác (ví dụ: với isatty()) hoặc khi được bật rõ ràng bằng tùy chọn dòng lệnh. Điều đó đặc biệt quan trọng đối với các máy đo tiến độ dựa trên hành vi cập nhật thiết bị đầu cuối để có ý nghĩa, như các thanh% -complete.

Đối với một số thông báo tiến trình rất đơn giản (Bắt đầu từ X X ... ... Xong với X,) hợp lý hơn là bao gồm đầu ra ngay cả đối với các luồng không tương tác. Trong trường hợp đó, hãy xem xét cách người dùng có thể tương tác với các luồng, như tìm kiếm grephoặc phân trang với lesshoặc theo dõi tail -f. Nếu có ý nghĩa để xem các thông điệp tiến bộ trong các bối cảnh đó, chúng sẽ dễ tiêu thụ hơn nhiều stdout.

POSIX định nghĩa lỗi tiêu chuẩn là

để viết đầu ra chẩn đoán

Điều này không giới hạn việc sử dụng nó chỉ thông báo lỗi. Tôi sẽ coi thông tin tiến trình là đầu ra chẩn đoán, vì vậy nó thuộc về lỗi tiêu chuẩn.

POSIX cụ thể hơn một chút về "thông tin chẩn đoán" trong Shell và Tiện ích , 1.4: Mặc định Mô tả Tiện ích (nhấn mạnh của tôi):

ĐẶT HÀNG

Phần STDERR mô tả đầu ra lỗi tiêu chuẩn của tiện ích. Chỉ những tin nhắn được gửi có chủ ý bởi tiện ích được mô tả. Việc sử dụng thiết bị đầu cuối cho lỗi tiêu chuẩn có thể khiến bất kỳ tiện ích tiêu chuẩn nào ghi đầu ra lỗi tiêu chuẩn dừng lại khi được sử dụng trong nền. Vì lý do này, các ứng dụng không nên sử dụng các tính năng tương tác trong các tập lệnh được đặt trong nền.

Định dạng của thông báo chẩn đoán cho hầu hết các tiện ích là không xác định, nhưng các quy ước về ngôn ngữ và văn hóa của thông báo chẩn đoán và thông tin có định dạng không được xác định bởi tập POSIX.1-2008 này sẽ bị ảnh hưởng bởi cài đặt LC_MESSAGES và [XSI] [Tùy chọn Bắt đầu ] NỀN TẢNG. [Kết thúc tùy chọn]

Đầu ra lỗi tiêu chuẩn được chỉ định của các tiện ích tiêu chuẩn sẽ không phụ thuộc vào sự tồn tại hoặc giá trị của các biến môi trường được xác định trong tập POSIX.1-2008 này, trừ khi được cung cấp bởi tập POSIX.1-2008 này.

Hành vi mặc định : Khi phần này được liệt kê là "Lỗi tiêu chuẩn chỉ được sử dụng cho các thông báo chẩn đoán.", Điều đó có nghĩa là, trừ khi có quy định khác, các thông báo chẩn đoán chỉ được gửi đến lỗi tiêu chuẩn khi trạng thái thoát cho biết có lỗi đã xảy ra và tiện ích được sử dụng như được mô tả bởi tập POSIX.1-2008 này.

Khi phần này được liệt kê là "Không được sử dụng.", Điều đó có nghĩa là lỗi tiêu chuẩn sẽ không được sử dụng khi tiện ích được sử dụng như được mô tả trong tập POSIX.1-2008 này.

IANASL, nhưng tôi giải thích điều đó có nghĩa là stderr sẽ chỉ có đầu ra nếu tiện ích sẽ trả về mã thoát lỗi. Vì đây không phải là tiến trình thông thường để thực hiện thành công, nên không có thông tin tiến trình nào được in bởi tiện ích POSIX trừ khi xảy ra lỗi (tất nhiên trừ khi có quy định khác, v.v.).

Theo nguyên tắc loại trừ, nó chỉ có thể đi đến stderr. Vâng, tôi biết bạn đã hỏi về một đặc điểm kỹ thuật chính thức, mà tôi không thể đưa ra cho bạn ngoài liên kết đến đặc tả POSIX, được đưa ra bởi Stephen Kitt, trong đó tuyên bố rằng stderr là dành cho mục đích chẩn đoán.

Điểm quan trọng hơn là stdin và stdout có chức năng không cho phép báo cáo tiến trình in ra thiết bị xuất chuẩn - tất nhiên chúng tạo thành chuỗi các đường ống mà trong các lệnh shell Unix không chỉ là tác dụng phụ, mà là cốt lõi của cách tiếp cận đường ống mạnh mẽ .

Vì thế. Không có gì ngoại trừ "tải trọng" thực sự của chương trình của bạn thuộc về thiết bị xuất chuẩn. Nếu chương trình của bạn không có đầu ra, thì không có gì nên vào stdout. Điều này để lại stderr cho mọi thứ khác , bao gồm các báo cáo tiến độ.

Cấp, điều này để lại một lỗ hổng - có lẽ sẽ rất tốt nếu có một "stdfluff" hoặc một cái gì đó tương tự không phải là đầu ra cũng không phải lỗi mà là báo cáo tiến trình, gỡ lỗi và somesuch. Trong thực tế, không có gì ngăn bạn làm điều đó, tức là, bạn có thể in tiến trình của mình để mô tả tệp 3. Ví dụ:

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

Điều này tạo ra không có đầu ra. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

Điều này in ra fd-3, được chuyển hướng đến thiết bị xuất chuẩn.

(*) Ví dụ đầu tiên không tạo ra đầu ra nhưng vẫn hơi xa; sự openthất bại và $!sẽ chứa đựng no such file or directory; chỉ cần lấy điều này làm ví dụ, tất nhiên không nên sử dụng như thế này một cách nghiêm túc. Trong một chương trình thực tế, nếu bạn muốn đi theo lộ trình này, bạn có thể kiểm tra xem /dev/fd/3có thể sử dụng được không và lấy đây làm gợi ý về việc có nên kích hoạt báo cáo tiến độ của bạn hay không; bạn phải làm điều đó khá sớm để bạn không bị nhầm lẫn bởi chính bạn openđối với các tệp thực và ...

Thông báo sử dụng sẽ đi đến thiết bị xuất chuẩn nếu người dùng đã gọi nó --helpvà gửi thông báo nếu họ mắc lỗi. In nó ra stderr vô điều kiện là đáng ghét vì nó làm cho việc xem nó với máy nhắn tin / grep / vv trở nên khó khăn hơn.

Ngoài ra, tôi có thể đề xuất một cách thứ ba: open / dev / tty cho các báo cáo tiến độ / spinners / vv.