Apakah ada POSIX, GNU, atau pedoman resmi lainnya tentang di mana laporan kemajuan dan informasi logging (hal-hal seperti "Melakukan foo; foo done") harus dicetak? Secara pribadi, saya cenderung menulisnya ke stderr sehingga saya dapat mengarahkan ulang stdout dan hanya mendapatkan output aktual program. Baru-baru ini saya diberi tahu bahwa ini bukan praktik yang baik karena laporan kemajuan sebenarnya bukan kesalahan dan hanya pesan kesalahan yang harus dicetak ke stderr.
Kedua posisi masuk akal, dan tentu saja Anda dapat memilih satu atau yang lain tergantung pada detail dari apa yang Anda lakukan, tetapi saya ingin tahu apakah ada standar yang diterima secara umum untuk ini. Saya belum dapat menemukan aturan khusus apa pun di POSIX, standar pengkodean GNU, atau daftar praktik terbaik lainnya yang diterima secara luas.
Kami memiliki beberapa pertanyaan serupa, tetapi pertanyaan tersebut tidak membahas masalah yang sebenarnya:
-
Kapan harus menggunakan pengalihan ke stderr dalam skrip shell:Jawaban yang diterima menyarankan apa yang cenderung saya lakukan, pertahankan keluaran akhir program di stdout dan yang lainnya ke stderr. Namun, ini hanya disajikan sebagai pendapat pengguna, meskipun didukung oleh argumen.
-
Haruskah pesan penggunaan masuk ke stderr atau stdout?:Ini khusus untuk pesan bantuan tetapi mengutip standar pengkodean GNU. Ini yang saya cari, tidak terbatas pada pesan bantuan saja.
Jadi, apakah ada aturan resmi tentang di mana laporan kemajuan dan pesan informatif lainnya (yang bukan merupakan bagian dari keluaran aktual program) harus dicetak?
Jawaban yang Diterima:
Posix mendefinisikan aliran standar sebagai berikut:
Saat program dimulai, tiga aliran harus ditentukan sebelumnya dan tidak perlu dibuka secara eksplisit:input standar (untuk membaca input konvensional), output standar (untuk menulis keluaran konvensional), dan kesalahan standar (untuk menulis keluaran diagnostik). Saat dibuka, aliran kesalahan standar tidak sepenuhnya disangga; input standar dan aliran output standar sepenuhnya buffer jika dan hanya jika aliran dapat ditentukan untuk tidak merujuk ke perangkat interaktif.
Pustaka GNU C menjelaskan aliran standar dengan cara yang sama:
Variabel:FILE * stdout
Aliran keluaran standar, yang digunakan untuk keluaran normal dari program.Variabel:FILE * stderr
Aliran kesalahan standar, yang digunakan untuk pesan kesalahan dan diagnostik yang dikeluarkan oleh program.
Dengan demikian, definisi standar memiliki sedikit panduan untuk penggunaan aliran di luar "keluaran konvensional/normal" dan "keluaran diagnostik/kesalahan." Dalam praktiknya, adalah umum untuk mengarahkan ulang salah satu atau kedua aliran ini ke file dan saluran, di mana indikator kemajuan akan menjadi masalah. Beberapa sistem bahkan memantau stderr untuk output dan menganggapnya sebagai tanda masalah. Oleh karena itu, informasi kemajuan tambahan yang murni bermasalah pada kedua aliran.
Alih-alih mengirim indikator kemajuan tanpa syarat ke salah satu aliran standar, penting untuk mengetahui bahwa keluaran kemajuan hanya sesuai untuk interaktif sungai. Dengan mengingat hal itu, saya sarankan untuk menulis penghitung kemajuan hanya setelah memeriksa apakah alirannya interaktif (mis., dengan isatty() ) atau ketika diaktifkan secara eksplisit oleh opsi baris perintah. Itu sangat penting untuk pengukur kemajuan yang mengandalkan perilaku pembaruan terminal agar masuk akal, seperti batang %-lengkap.
Untuk pesan kemajuan tertentu yang sangat sederhana (“Mulai X” … “Selesai dengan X”), lebih masuk akal untuk menyertakan output bahkan untuk aliran non-interaktif. Dalam hal ini, pertimbangkan bagaimana pengguna dapat berinteraksi dengan aliran, seperti menelusuri dengan grep atau paging dengan less atau memantau dengan tail -f . Jika masuk akal untuk melihat pesan kemajuan dalam konteks tersebut, pesan tersebut akan lebih mudah digunakan dari stdout .